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.
Citace od: Mirek Prýmek kdy 08. 11. 2012, 13:30:14
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
Citace od: Ondřej Caletka kdy 08. 11. 2012, 14:23:37
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=0Tomu 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.
Citace od: lucie2165 kdy 08. 11. 2012, 15:48:15
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