Zobrazit příspěvky

Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.


Příspěvky - - -

Stran: 1 [2] 3
16
Ahoj, byl bych moc vděčný za radu. Nový počítač podporuje podle všeho jen UEFI, ne BIOS MBR/legacy.
A já mám ve starém PC šifrovaný LUKS disk s MBR. Takže když změním UEFI boot tak POST hlásí 3F0 chybu a s diskem se nebaví.

Zjistil jsem, že je asi potřeba vytvořit EFI oddíl, jenže problém je jak. Když v gparted dešifruju ten LUKS disk, tak není vidět boot oddíl , jen ext4 a gparted říká: Cant have a partition outside the disk! (díky tomu nelze disk zálohovat pomocí FIleZilla, RedoBackup fungoval)

$ sudo fdisk -l /dev/sda* ukazuje jen 1 oddíl:

Citace
    Disklabel type: dos
    Disk identifier: 0xc75ac368

    Device Boot Start End Sectors Size Id Type
    /dev/sda1 * 2048 234436544 234434497 111,8G 83 Linux

$ sudo gdisk -l /dev/sda ukazuje:

Citace
    GPT fdisk (gdisk) version 1.0.6

    Warning: Partition table header claims that the size of partition table
    entries is 1153912944 bytes, but this program supports only 128-byte entries.
    Adjusting accordingly, but partition table may be garbage.
    Warning: Partition table header claims that the size of partition table
    entries is 0 bytes, but this program supports only 128-byte entries.
    Adjusting accordingly, but partition table may be garbage.
    Partition table scan:
    MBR: MBR only
    BSD: not present
    APM: not present
    GPT: not present
    …
    Partition table holds up to 128 entries
    Main partition table begins at sector 2 and ends at sector 33
    First usable sector is 34, last usable sector is 234441614
    Partitions will be aligned on 2048-sector boundaries
    Total free space is 7084 sectors (3.5 MiB)

    Number Start (sector) End (sector) Size Code Name
    1 2048 234436544 111.8 GiB 8300 Linux filesystem

Jak byste tedy postupovali ohledně umožnění UEFI bootování z toho disku? Pod odkazem v prvním odstavci jsou popsané postupy jak pracovat s grub ohledně EFI, nevím ale jestli to stačí, protože podle manuálu pro můj systém se uvádí že potřebuju asi 300MB EFI oddíl FAT32, asi s boot a esp flag.

děkuji

17
Sítě / Re:NAT prerouting pravidlo iptables neotevře port
« kdy: 18. 04. 2020, 11:27:04 »
AKTUALIZACE:

musíte dělat na paketech směřujících do VPN, tedy -o tun0 místo -o eth0.

Je možné, že to není nutné udělat, protože to funguje zdá se i bez toho (v iptables pravidlech na serveru nemám žádné tun ale jen eth). Začalo to fungovat, když jsem smazal zahazovací (DROP) pravidlo na konci FORWARD:

Citace
iptables -L FORWARD --line-numbers
Chain FORWARD (policy ACCEPT)
num target prot opt source destination
1 ACCEPT all -- 10.8.0.0/24 anywhere
2 ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
3 DROP all -- anywhere anywhere ctstate INVALID
4 ACCEPT all -- anywhere anywhere ctstate RELATED,ESTABLISHED
5 ACCEPT all -- anywhere anywhere
6 ACCEPT all -- 192.168.42.0/24 192.168.42.0/24
7 ACCEPT all -- anywhere 192.168.43.0/24 ctstate RELATED,ESTABLISHED
8 ACCEPT all -- 192.168.43.0/24 anywhere
9 DROP all -- anywhere anywhere

iptables -D FORWARD 9

Další detaily, (iptables -t nat -L --line-numbers):
Citace
Chain PREROUTING (policy ACCEPT)
num  target     prot opt source               destination
1    PREROUTING_direct  all  --  anywhere             anywhere
2    PREROUTING_ZONES_SOURCE  all  --  anywhere             anywhere
3    PREROUTING_ZONES  all  --  anywhere             anywhere
4    DNAT       tcp  --  anywhere             anywhere             tcp dpt:12345 to:127.0.0.1:1082
5    DNAT       tcp  --  1.2.3.0/24       anywhere             tcp dpt:ftp to:1.2.3.5:21
6    DNAT       udp  --  anywhere             anywhere             udp dpt:ddi-udp-2 to:10.8.0.2:8889
7    DNAT       tcp  --  anywhere             anywhere             tcp dpts:48280:48285 to:10.8.0.2
8    DNAT       udp  --  anywhere             anywhere             udp dpts:48280:48285 to:10.8.0.2

Chain INPUT (policy ACCEPT)
num  target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
num  target     prot opt source               destination
1    OUTPUT_direct  all  --  anywhere             anywhere

Chain POSTROUTING (policy ACCEPT)
num  target     prot opt source               destination
1    POSTROUTING_direct  all  --  anywhere             anywhere
2    POSTROUTING_ZONES_SOURCE  all  --  anywhere             anywhere
3    POSTROUTING_ZONES  all  --  anywhere             anywhere
4    SNAT       all  --  10.8.0.0/24         !10.8.0.0/24          to:ipserveru
5    MASQUERADE  all  --  192.168.42.0/24      anywhere
6    MASQUERADE  all  --  192.168.43.0/24      anywhere             policy match dir out pol none
7    MASQUERADE  all  --  anywhere             anywhere
8    MASQUERADE  all  --  anywhere             anywhere
(pokus o přesměrování IP rozsahu tcp i udp jako jedno pravidlo)

18
Předpokládám, že o to jste se pokoušel tou maškarádou – tohle ale musíte dělat na paketech směřujících do VPN, tedy -o tun0 místo -o eth0.
Děkuji za odpověď. Ten OpenVPN server u kterého mi otevření portu fungovalo, vypadal takto:

iptables-save|grep -i mas
Citace
-A POSTROUTING -o venet0 -j MASQUERADE

ten, který mi teď nefunguje:

iptables-save|grep -i mas
Citace
-A POSTROUTING -s 192.168.42.0/24 -o eth0 -j MASQUERADE
-A POSTROUTING -s 192.168.43.0/24 -o eth0 -m policy --dir out --pol none -j MASQUERADE
-A POSTROUTING -j MASQUERADE
-A POSTROUTING -o eth0 -j MASQUERADE

zkusil jsem tedy odebrat postupně ta 3 první MASQUERADE pravidla a pak i tomu poslednímu nastavit tun0 místo eth0 a ani jedno nefungovalo aby ten TCP port byl otevřený. Stále ta aplikace říká, že její port pro příchozí TCP spojení je zavřený. "sudo nmap -p 48280-48289 vpnserverIP" spuštěný z jiného počítače a IP ukazuje ten TCP port jako "filtered" a https://check-host.net/check-tcp "Connection timeout". Přitom firewall je na klientu vypnutý a wireshark na klientu nezachytil žádný packet odpovídající tomu tcp portu. Jinak na ten tcp port míří spoustu připojení podle toho co ukazuje na serveru spuštěný příkaz tcpdump -i eth0 tcp port 48280 ...

19
Malá aktualizace.
https://check-host.net/check-udp ukazuje, že ty mnou přesměrované UDP porty se ukazují jako otevřené nebo filtrované, což je dobré znamení. Ostatní které jsem nesměroval se tam ukazují jako zavřené.
https://check-host.net/check-tcp ukazuje, že TCP porty, i ty mnou přesměrované jsou zavřené.
Nevím tedy kde je zádrhel že UDP jde a TCP se nepřesměruje (Wireshark na klientu TCP packety narozdíl od UDP neukazuje, při testu byl firewall na klientu vypnutý).

20
Děkuji oběma za cennou reakci. Tak jsem se v tom babral asi další 4 hodiny a TCP stále není otevřený. Snažil jsem se to níže sepsat co nejčitelněji ale nepřeju vám tento příběh číst.

SOUHRN:
Podle tcpdump data na server přicházejí. Pravidlo, které je má přesměrovat tam zdá se je. iptables loguje data pro ten port, nemohu však najít žádná na protokolu TCP, jen UDP. Wireshark na klientu trafik zobrazuje, ale zdá se, že jen UDP a GVSP, ne TCP... Rád bych ověřil nějak že UDP port je skutečně otevřený, našel jsem následující příkazy ale potřebovaly bynejspíš upravit:
vpn klient: ncat -u -l -p 48280
jiný pc v internetu: nping --udp -p 48280 --data-string 'hello' -c 1 vpnserverIP
Nevím tedy A) proč se zdá že nefunguje TCP přesměrování portu a B) jestli funguje UDP a kterými příkazy to zjistím

PODROBNĚ:

Topologie je jak uvádíte - server v internetu a klient v síti LAN, kde je klient napojený na obyčejný WAN router (ten datový tok VPN šifrovaný na klientu jen předává na server a zpět na klienta).

Ano, net.ipv4.ip_forward je zapnutý v /etc/sysctl.conf
Aplikace na klientu je zapnutá a měla by na portu 48280 naslouchat. (je to Transmission a port je u toho nastavený správně)

Wireshark na klientu ukazuje u toho portu který chci přesměrovat záznamy (protokol GVSP) kde se objevuje "[RANGE_ERROR] [BLOCK_DROPPED]" někdy PACKET_RESEND a unknown payload type. Možná je to tak správně, nevím, je to šifrovaný VPN trafik na tun0. Pak jsou tam ještě záznamy protokolu ne GVSP ale UDP. Žádné záznamy TCP. (Transmission software na klientu při kontrole otevřenosti portu 48280 uvádí že kontroluje TCP port...; zkoušel jsem i jiný software a TCP port(+ forwarding), ale je také "zavřený")
Myslel jsem, že ten program Transmission by měl fungovat na UDP ale jeví známky, že nefunguje - možná že je to tím, že torrent vyžaduje pro navázání TCP, nevím.

"tcpdump -i eth0 port 48280" na serveru pak ukazuje packety:
Citace
15:34:28.123456 IP nejakehostname.61566 > mojehostname.48280: Flags \[S\], seq 857936979, win 64240, options [mss 1452,nop,wscale 8,nop,nop,sackOK], length 0

Zkoušel jsem zapnout logování na serveru (iptables -A INPUT -j LOG) - nevím zda správně (iptables ukazuje "LOG level warning"), ale ledackteré síťové záznamy se přidávají do kernel logu /var/log/messages, u toho UDP portu 48280 se našly záznamy jako:
Citace
Apr 17 15:11:40 let kernel: IN=eth0 OUT= MAC=*** SRC=ciziipadresa DST=mojeipadresaserveru LEN=132 TOS=0x00 PREC=0x20 TTL=113 ID=26107 PROTO=UDP SPT=33078 DPT=48280 LEN=112
v případě tcp protokolu se ale žádné záznamy nezalogovaly :-/, byť tcpdump trafik daného portu zobrazuje. (třeba "tcpdump -i eth0 tcp port 48280")
https://www.yougetsignal.com/tools/open-ports/ a software na klientu ale stále zobrazuje port jako uzavřený.

"iptables -P FORWARD ACCEPT" jsem zkusil, ale politika ale "Chain FORWARD (policy ACCEPT)" už tam bylo.

# iptables -L FORWARD
Citace
Chain FORWARD (policy ACCEPT)
target     prot opt source               destination
ACCEPT     all  --  anywhere             anywhere             state RELATED,ESTABLISHED
ACCEPT     all  --  10.8.0.0/24          anywhere
DROP       all  --  anywhere             anywhere             ctstate INVALID
ACCEPT     all  --  anywhere             anywhere             ctstate RELATED,ESTABLISHED
ACCEPT     all  --  anywhere             anywhere
ACCEPT     all  --  192.168.42.0/24      192.168.42.0/24
ACCEPT     all  --  anywhere             192.168.43.0/24      ctstate RELATED,ESTABLISHED
ACCEPT     all  --  192.168.43.0/24      anywhere
DROP       all  --  anywhere             anywhere

# iptables -L -t nat|grep DNAT
Citace
DNAT       tcp  --  anywhere             anywhere             tcp dpt:12345 to:127.0.0.1:1082
DNAT       tcp  --  ciziip.0/24       anywhere             tcp dpt:ftp to:ipmehoserveru:21
DNAT       udp  --  anywhere             anywhere             udp dpt:ddi-udp-2 to:10.8.0.2:8889
DNAT       tcp  --  anywhere             anywhere             tcp dpt:48280 to:10.8.0.2:48280
DNAT       tcp  --  anywhere             anywhere             tcp dpt:48281 to:10.8.0.2:48281
DNAT       udp  --  anywhere             anywhere             udp dpt:48281 to:10.8.0.2:48281
DNAT       udp  --  anywhere             anywhere             udp dpt:48280 to:10.8.0.2:48280

děkuji za reakce a případné nápady co zkusit

21
Sítě / NAT prerouting pravidlo iptables neotevře port
« kdy: 16. 04. 2020, 18:03:30 »
Ahoj, potřeboval bych pomoct s tím jak zjistit proč se mi neotevřel port.

Na Linux (CentOS 7) serveru, který slouží jako proxy (díky OpenVPN) jsem se pokusil otevřít port stejně jako se mi to povedlo na mém jiném serveru běžícím na CentOS 6. Pravidlo:

iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 48280 -j DNAT --to 10.8.0.2:48280

eth0 protože jediná síťová rozhraní "ifconfig" na serveru zobrazí lo, eth0 a tun0(VPN)
10.8.0.2 je rozhraní ukazující se na VPN klientu

no ale port se ukazuje jako uzavřený (pomocí software na klientu i pomocí online port checkeru)
Na klientu jsem i vypnul firewall ale nepomohlo

Jak tedy teď zjistit co je špatně a kde ten trafik naráží na zeď? Nevím jestli může nějak pomoci TCPdump
Jak už jsem zmínil prakticky stejné iptables pravidlo mi fungovalo na jiném openvpn serveru.

PS: pár dalších detailů (jako verze OS, iptables a kernel moduly, apod.) je zde

22
Server / Re:Tor exit node - zkušenosti
« kdy: 24. 11. 2019, 13:44:44 »
Zde jsou tipy jak redukovat možnost zneužití Tor exitu:
https://blog.torproject.org/tips-running-exit-node
https://community.torproject.org/relay/setup/exit/
A zde FAQ:
https://www.torproject.org/eff/tor-legal-faq.html.en
pokud neumíte anglicky, tak překladač Google Translate.
Já bych tedy tor-exit provozoval jen z pronajatého serveru někde v datovém centru a navíc pronajatého an0nymně.

23
Server / Re:IP route ukazuje jen 169.254.0.0/16
« kdy: 02. 10. 2019, 21:16:14 »
V těch výše uvedených "perl" příkazech je chyba (psal jsem to moderátorovi, ale neopravil to). perl na centos6 není, potřeba použít v příkazech místo "perl -pi -e" toto: "sed -i". A nezapomenou nahradit "myvpspubliciphere" skutečnou veřejnou IP serveru. Ohledně DNS serverů v těch příkazech je možné použít univerzální 1.1.1.1 a 8.8.8.8 .

24
Server / Re:ip route ukazuje jen 169.254.0.0/16
« kdy: 26. 09. 2019, 11:56:09 »
Zkousels ty uvozovky vlozit pomoci alt+ASCII? Alt+34 myslim
právě jsem to zkusil a nepovedlo se. zkusil jsem oba alty a obě numerické klávesnice. i samo vkládání přes clipboard které teď funguje překonvertuje ty znaky na jiné. naštěstí už je ten problém se sítí vyřešen viz. výše.

25
Server / Re:ip route ukazuje jen 169.254.0.0/16
« kdy: 24. 09. 2019, 22:04:30 »
Ne-escapeovana mezera prerusi parametr ... Jestli jde vlozit $
$ to taky neumí, ale když se mezera escapuje zpětným lomítkem, tak to fungovalo. příkaz který fungoval:
Kód: [Vybrat]
perl -pi -e s/multi\ on/172.31.1.1\\/32\ dev\ eth0\\ndefault\ via\ 172.31.1.1\ dev\ eth0/g /etc/sysconfig/network-scripts/route-eth0

Výsledek je tedy to, že jsem se pokusil nastavit statickou konfiguraci, viz https://wiki.hetzner.de/index.php/Cloud_IP_static/en#Fedora_.2F_CentOS

Díky mizerné Hetzner konzoli, která neumí Ctrl a další důležité znaky (| " ' > $) jsem tu static konfiguraci nakonec udělal těmito příkazy:
Kód: [Vybrat]
perl -pi -e s/BOOTPROTO=dhcp/BOOTPROTO=static/g /etc/sysconfig/network-scripts/ifcfg-eth0
perl -pi -e s/IPV6INIT=no/IPADDR=myvpspubliciphere/g /etc/sysconfig/network-scripts/ifcfg-eth0
perl -pi -e s/ONBOOT=yes/ONBOOT=yes\\nNETMASK=255.255.255.255\\nDNS1=213.133.98.98\\nDNS2=213.133.99.99/g /etc/sysconfig/network-scripts/ifcfg-eth0
cp /etc/host.conf /etc/sysconfig/network-scripts/route-eth0
perl -pi -e s/multi\ on/172.31.1.1\\/32\ dev\ eth0\\ndefault\ via\ 172.31.1.1\ dev\ eth0/g /etc/sysconfig/network-scripts/route-eth0
service network restart

a na obrázku v příloze vidíte výsledek (route a ifconfig). Začalo to pak odpovídat na ping a SSH  :D
Děkuji tedy za pomoc, motal jsem se v tom celý den. Třeba to bude někomu kdo používá Hetzner cloud server atd. v budoucnu ještě užitečné.

26
Server / Re:ip route ukazuje jen 169.254.0.0/16
« kdy: 24. 09. 2019, 16:40:32 »
Zkusil jsem tedy do /etc/sysconfig/network-scripts/ifcfg-eth0 doplnit:
NETMASK=255.255.255.255
DNS1=213.133.98.98
DNS2=213.133.99.99
(perl -pi -e s/ONBOOT=yes/ONBOOT=yes\\nNETMASK=255.255.255.255\\nDNS1=213.133.98.98\\nDNS2=213.133.99.99/g /etc/sysconfig/network-scripts/ifcfg-eth0)

pak chci vytvořit soubor route-eth0
cp /etc/host.conf /etc/sysconfig/network-scripts/route-eth0
perl -pi -e s/multi on/172\.31\.1\.1\/32 dev eth0\\ndefault via 172\.31\.1\.1 dev eth0/g /etc/sysconfig/network-scripts/route-eth0

Ale chyba je: Substitution pattern not terminated at -e line 1.

Dělám to tak komplikovaně, protože Hetzner web konzole zdá se neumí Ctrl klávesu (v editoru vim), " ' >> | - , takže echo "" >> soubor apod. nejde. Nevíte co je špatně v tom perl příkazu?

27
Server / Re:ip route ukazuje jen 169.254.0.0/16
« kdy: 24. 09. 2019, 16:05:47 »
https://wiki.hetzner.de/index.php/Cloud_IP_static/en
Díky to byl dobrý link, bohužel ta web konzole pro správu nepodporuje Ctrl > " ' a | (ani když to vložím přes clipboard - nahradí se to něčím jiným, třeba | tečkou), takže nevím teď jak mám ty soubory editovat. Podařilo se mi nahradit v souboru BOOTPROTO=dhcp na BOOTPROTO=static a pak nahradit IPV6... za IPADDR=mojevpsipv4
(použil jsem k tomu příkaz bez uvozovek:)
perl -pi -e s/BOOTPROTO=dhcp/BOOTPROTO=static/g /etc/sysconfig/network-scripts/ifcfg-eth0

bohužel po restartu network, to stále nefunguje, routing table teď obsahuje navíc:
116.0.0.0/8 dev eth0 proto kernel scope link src 116.mojevpsip...

Díval jsem se na jiný server u jiného providera, který běží na stejném OS a patří do /29 subnetu a jeho routing tabulka se trochu podobá:
*.*.*.136/29 dev em1  proto kernel  scope link  src *.*.*.138
169.254.0.0/16 dev em1  scope link  metric 1002
default via *.*.*.137 dev em1

(to VPSko nevím do jakého subnetu patří a jaká bude jeho gateway IP jestli taková je a hraje zde roli)

Divné mi je to co vidím pod ifconfig:
ve výstupu pod eth0 je kromě mé veřejné IP nastavené pod inet addr i "Bcast" 116.255.255.255 (116 je první část z té mojí veřejné IP) Říkám si, jestli to není tím, že jsem do toho konfiguračního souboru eth0 NEvložil následující:
NETMASK=255.255.255.255
DNS1=213.133.98.98
DNS2=213.133.99.99

Máš to nakonfigurovaný na dhcp. ...
Mozna pro tebe bude lepsi utilita 'system-config-network-tui' pres kterou tam namatis adresy, ktere jsi dostal.

Ano, myslel jsem že dhcp může být. Teď jsem tedy zkusil BOOTPROTO static, viz výše, ale to také nefungovalo.
system-config-network-tui -> command not found a do internetu se nepřipojím abych si to stáhnul

Poskytovatel mi píše: "You are missing the netmask and the route file. Please follow the steps in this wiki article:

https://wiki.hetzner.de/index.php/Cloud_IP_static/en#Fedora_.2F_CentOS"

28
Server / IP route ukazuje jen 169.254.0.0/16
« kdy: 24. 09. 2019, 13:26:47 »
Ahoj, prosím o radu jak nastavit routing tabulku u cloud serveru Hetzner.
Nainstaloval jsem tam pomocí jejich web konzole CentOS 6.10 a nejde internet, pingnout z/do serveru.
"ip r" ukazuje pouze:
169.254.0.0/16 dev eth0 scope link metric 1002

Už jsem četl na https://wiki.hetzner.de/index.php/CloudServer/en#What_are_Routes.3F že "The special private IP Address `172.31.1.1`. This IP address is being used as a default gateway of your servers public network interface. "

takže bych měl použít tu IP adresu jako bránu. To jsem zkoušel:
route add 172.31.1.1 eth0
route add default gw 172.31.1.1 eth0
ale nepomáhá to

konfigurační soubor eth0: https://i.postimg.cc/9Qc6VwK7/ifcfg-eth0.gif

29
head /etc/vimrc

if v:lang =~ "utf8$" || v:lang =~ "UTF-8$"
   set fileencodings=ucs-bom,utf-8,latin1
endif

v PuTTY je kódování UTF-8

dám kurzor do českého textu, a jakmile napíši první znak text odskočí a vidím že píši pár znaků vedle

30
Hello,
on the server with Apache are hosted several websites. One websites login form is the target of some kind of distributed attack/bruteforce password cracking.

I see like 5000 IPs accessing that login page politely, not aggressively. I am sure these are not humans.
A few visits per IP and slowly growing.

I can firewall deny manually some subnets like 123.45.*.* etc. and i can also ban many hundred IPs directly in firewall, but i am afraid of high memory usage of the kernel because too many iptables rules. Is there any better way to prevent server overloading. Like mod security way, i am running CSF firewall too.

Thank you

Stran: 1 [2] 3