Fórum Root.cz
Hlavní témata => Sítě => Téma založeno: lucie2165 08. 11. 2012, 12:29:31
-
Ahojky,
objevila jsem problem s natovanim portu na stejny dport a nevim si rady.
192.168.1.40 port 3389 - server1
192.168.1.100 port 3389 - server2
1.1.1.1:33389 pristup zvenku na server2
1.1.1.1:33390 pristup zvenku na server1
eth1 = vnejsi sitovka
eth0 = vnitrni sit
Na server2 se zvenku dostanu, ale na server1 se nedostanu.
Kdyz dam iptables -L tak se me obe presmerovani ukazou.
iptables -F
echo 1 > /proc/sys/net/ipv4/ip_forward
/sbin/iptables -t nat -A PREROUTING -p tcp --dport 33390 -i eth1 -j DNAT --to 192.168.1.40:3389
iptables -A FORWARD -i eth1 -o eth0 -p tcp -d 192.168.1.40 --dport 3389 -j ACCEPT
iptables -A INPUT -i eth1 -p tcp --dport 3389 -j ACCEPT
/sbin/iptables -t nat -A PREROUTING -p tcp --dport 33389 -i eth1 -j DNAT --to 192.168.1.100:3389
iptables -A FORWARD -i eth1 -o eth0 -p tcp -d 192.168.1.100 --dport 3389 -j ACCEPT
iptables -A INPUT -i eth1 -p tcp --dport 3389 -j ACCEPT
/sbin/iptables -A INPUT -m limit --limit 1000/minute -j LOG \
--log-level 7 --log-prefix "Dropped INPUT by firewall: "
v logu to vypada takto
Nov 8 02:07:14 dmz kernel: [ 2298.097931] Dropped INPUT by firewall: IN=eth1 OUT= MAC=00:05:5d:81:c5:ac:00:12:ef:61:00:04:08:00 SRC=2.2.2.2 DST=1.1.1.1 LEN=40 TOS=0x08 PREC=0x20 TTL=241 ID=65259 PROTO=TCP SPT=28105 DPT=33390 WINDOW=65535 RES=0x00 RST URGP=0
Uz nevim kde delam chybu. Presmerovani na vnitrni porty pouzivam uz delsi dobu ale toto je poprve kdy si nevim rady.
Dekuji za pomoc
-
Ha! Holka, linuxačka a ještě takový krásný dotaz :) Nebo kluk, linuxák, s problémem s genderovou identitou a takový krásný dotaz!
Iptables používám zřídka, takže možná řeknu blbost, protože si přesně nepamatuju, jak tam navazují ty chainy, ale na první pohled mě tam mate tohle: podle logu ti to dropne paket hned při vstupu: SRC=2.2.2.2 DST=1.1.1.1 SPT=28105 DPT=33390 - a nikde tam nevidím pravidlo, které by takový paket povolovalo. Povoluješ až znatovaný paket (--dport 3389).
Nechápu ale, jak se můžeš na jeden stroj dostat a na druhý ne, to je nějaký divný.
-
Nikdy jsem packety nepovolovala a chodi me takto 40 pravidel, ale jen u toho jednoho me to nefunguje. A jsem holka a 18 let delam ajtarinu. Linux, Mac, Widle od 3.1. Ale doopravdy si ted nevim rady.
-
Pokud je to to, co mi prijde, ze by to snad mohlo byt (podle zaznamu z logu), tak by melo pomoct pridat:
iptables -A INPUT -i eth1 -p tcp --dport 33389 -j ACCEPT
iptables -A INPUT -i eth1 -p tcp --dport 33390 -j ACCEPT
-
Tak jsem pridala povoleni portu a v logu nemam nic o odmitnuti paketu, ale stejne se na ten server nedostanu.
Tak tam bude jeste nejaka jina bota.
-
Pokud je to to, co mi prijde, ze by to snad mohlo byt (podle zaznamu z logu), tak by melo pomoct pridat:
iptables -A INPUT -i eth1 -p tcp --dport 33389 -j ACCEPT
iptables -A INPUT -i eth1 -p tcp --dport 33390 -j ACCEPT
Tím přidáváte pravidla na konec chainu INPUT, nikde nemáte zaručeno že vám paket nějaké předchozí pravidlo nezamítne! Proto bych doporučoval radši pravidla přidat na začátek, t.j. -I místo -A.
-
Napsala jsem to do zacatku spousteciho souboru takze by to nemelo zamitnout. V iptables -L je to na prvnim miste. Tam chyba nebude.
-
Vypadá to všechno dobře. Povolovat nepřesměrovaný port je zbytečné, k přemapování dochází ještě před vstupem do tabulky filter. Podle mě to bude nějaká banalita jako překlep. Doporučuji pomocí iptables -t nat -L PREROUTING -v sledovat stav počítadel. Pokud tam jsou nuly, někde je chyba. Pak bych začal postupně odebírat omezující podmínky a případně přidával sledovací target LOG.
Taky by mohl být problém, pokud je z dané kombinace zdrojové a cílové adresy a portu už vedené nějaké spojení, které eviduje conntrack − tabulka nat se totiž prochází jen pro paket začínající nové spojení. Sice si nedokážu představit, jak by k něčemu takovému mohlo dojít, ale je potřeba na to myslet.
-
pravidla vyzeraju v poriadku, podla netfilter packet flow http://upload.wikimedia.org/wikipedia/commons/3/37/Netfilter-packet-flow.svg (http://upload.wikimedia.org/wikipedia/commons/3/37/Netfilter-packet-flow.svg) , packet prechadza najprv nat PREROUTING, a potom by mal pokracovat vo filter FORWARD a cely INPUT obchadzat.
co hovori pocet packetov v pravidlach v iptables -vnL , iptables -vnL -t nat a tcpdump na oboch interfacoch , pripadne aj tcpdump na server2 ?
-
Packety i velikost postupne vzrusta
12 768 DNAT tcp -- eth1 any anywhere anywhere tcp dpt:33390 to:192.168.1.40:3389
ale na interface eth0 zadny provoz nevidim. :-(
-
vypis tcpdump -i eth1 -vv
14:50:01.801570 IP (tos 0x28, ttl 50, id 50525, offset 0, flags [DF], proto TCP (6), length 64)
d.e.cz.27368 > a.b.cz.33390: Flags , cksum 0xcd54 (correct), seq 403223764, win 65535, options [mss 1452,nop,wscale 1,nop,nop,TS val 1552447400 ecr 0,sackOK,eol], length 0
-
tak potom tipujem, ze packet zabludi niekde vo filter FORWARD, vzrasta pocet packetov aj v pravidle
iptables -A FORWARD -i eth1 -o eth0 -p tcp -d 192.168.1.40 --dport 3389 -j ACCEPT ?
-
iptables -L FORWARD -v
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
235K 282M ACCEPT all -- eth1 eth0 anywhere anywhere state NEW,RELATED,ESTABLISHED
169K 36M ACCEPT all -- eth0 eth1 anywhere anywhere
0 0 ACCEPT tcp -- eth1 eth0 anywhere vario.mac tcp dpt:3389
0 0 ACCEPT tcp -- eth1 eth0 anywhere mail.mac tcp dpt:smtp
0 0 ACCEPT tcp -- eth1 eth0 anywhere mail.mac.cz tcp dpt:5900
0 0 ACCEPT tcp -- eth1 eth0 anywhere mail.mac tcp dpt:3283
0 0 ACCEPT tcp -- eth1 eth0 anywhere mail.mac.cz tcp dpt:imaps
0 0 ACCEPT tcp -- eth1 eth0 anywhere mail.mac tcp dpt:https
0 0 ACCEPT tcp -- eth1 eth0 anywhere mail.mac.cz tcp dpt:pop3
0 0 ACCEPT tcp -- eth1 eth0 anywhere mail.mac tcp dpt:www
0 0 ACCEPT tcp -- eth1 eth0 anywhere mail.mac.cz tcp dpt:ftp
0 0 ACCEPT tcp -- eth1 eth0 anywhere servermac.mac tcp dpt:3389
0 0 ACCEPT tcp -- eth1 eth0 anywhere variovirt.mac tcp dpt:3489
0 0 ACCEPT tcp -- eth1 eth0 anywhere mail.mac tcp dpt:imap2
-
Vypadá to všechno dobře. Povolovat nepřesměrovaný port je zbytečné, k přemapování dochází ještě před vstupem do tabulky filter.
Ja vedel, ze se s tema chainama spletu ;)
Jaktoze ale pak to v tom logu vypada takhle:
Nov 8 02:07:14 dmz kernel: [ 2298.097931] Dropped INPUT by firewall: IN=eth1 OUT= MAC=00:05:5d:81:c5:ac:00:12:ef:61:00:04:08:00 SRC=2.2.2.2 DST=1.1.1.1 LEN=40 TOS=0x08 PREC=0x20 TTL=241 ID=65259 PROTO=TCP SPT=28105 DPT=33390 WINDOW=65535 RES=0x00 RST URGP=0
Tomu vubec nerozumim. DST, ktere loguje, je to jeste nezmenene (puvodni) DST, prestoze v paketu uz je jine? Nebo co je to za magii?
-
Ten výpis iptables -L FORWARD -v je divný. První pravidlo povolí veškerou komunikaci ven, další pravidlo povolí veškerou komunikaci dovnitř. Takže další pravidla už jsou zbytečná. A nakonec policy ACCEPT, která povolí také všechno.
Firewall tu komunikaci určitě nezastavuje, tam to máte povolené hned třikrát. Zaměřil bych se na směrovací tabulku případně směrovací pravidla. ip route a ip rule. Jestli ty pakety náhodou neodchází někam jinam, než kam si představujete.
-
Takze zahada odhalena. Spatna gateway na serveru. Tak dlouho hledam chybu jinde a zapomenu zkontrolovat nastaveni site na serveru. V ramci site to obchazi router, ale pri ceste ven to slo do stoupy.
Diky za pomoc.
-
mimochodom, vsetky pravidla vo Forward su zbytocne, kedze je nastavena default policy accept.
-
Takze zahada odhalena. Spatna gateway na serveru. Tak dlouho hledam chybu jinde a zapomenu zkontrolovat nastaveni site na serveru. V ramci site to obchazi router, ale pri ceste ven to slo do stoupy.
No a co teda ten matoucí log?
-
Podle me to vyhodnotilo jako vadny packet a proto to blokovalo.
Nyni uz to funguje dobre a muzu zavirat fw.
Diky