Dotaz: proč nechodí NAT?

[krnoha]

Mám testovací router na jádře 2.6.34.7 . Vnitřní síť je privátní a je v ní jeden stroj, na kterém běží ping směrem ven. Každou sekundu na vnějším stroji vidím

18:02:40.636985 IP 192.168.1.51 > vnejsistroj.fzu.cz: ICMP echo request, id 11023, seq 6813, length 64
18:02:40.664039 IP vnejsistroj.fzu.cz > 192.168.1.51: ICMP echo reply, id 11023, seq 6813, length 64

V iptables nemám nic, router správně routuje. Teď na routeru napíšu:

iptables -t nat -A POSTROUTING  -s 192.168.1.0/24 -j SNAT --to-source router-IP

Následující

iptables -t nat -L

mi ukáže, že to pravidlo tam je. Na vzdáleném stroji bych teď čekal něco jako

18:02:40.636985 IP router-IP > vnejsistroj.fzu.cz: ICMP echo request,
18:02:40.664039 IP vnejsistroj.fzu.cz  > router-IP

Ale houby, router jako by pravidlo neviděl dál si mele svou. Musím dělat něco špatně, ale zaboha to nevidím. Zkusil by mě někdo postrčit?

Odpovědi

[krnoha]

Odpovím si sám. Napsal jsem to do startovního skriptu a provedl reboot. NAT funguje. Předtím jsem dělal rovněž rebooty a potom jsem psal definici NAT z klávesnice, To pořád nechtělo fungovat. Možná byl problém v tom, že ty pingy tam byly každou sekundu a něco v jádře se nestačilo vzpamatovat. Nebo byl problém možná v něčem jiném. Zatracenej život.

[krnoha]

Jenže po dalším rebootu NAT znovu nechodí. Zkusím nainstalovat nějaké peče.

[zelo81]

najskor pouzi distribucne jadro ak to nejak blbne pri tomto, navyse to co tu pises chodilo korektne predtym? myslim ze asi to nechodilo vobec: man iptables

[krnoha]

Běhalo mi to před několika lety na jiném stroji. Prostředí bylo jiné ale základní konstrukce byla stejná. To jádro je defaultní v distribuci OpenSuSE 11.3. Plným označením je to 2.6.34.7-0.7-default .

[pht]

Vidět znamená věřit :) Záleží na kterém interface to vidíte. NeNATované adresy budou na interface vnitřním, NATované na vnějším (viz tcpdump -i). Pokud ping funguje, tj. vidíte příchozí ICMP paket, tak je velmi pravděpodobné, že NAT funguje, akorát koukáte na špatný interface.

[krnoha]

tcpdump pouštím na vzdáleném na vzdáleném stroji, na tom na který jsem poslal ping request. Vidím tam to co jsem psal, že paket přišel na správné místo, ale jeho zdrojová adresa není přepsaná. Ten vzdálený stroj odpovídá na zdrojovou adresu, čili odpověď pošle na default router a ten ji zahodí. Všecko funguje jak má, až na přepis zdrojové adresy. Rovněž je pravda co jsem už napsal, že po jednom rebootu NAT obživnul. Stroj ve vnitřní síti v té době správně dostával odpovědi na ping a tvářil se spokojeně, stejně jako já. Jenže další pokusný reboot to znovu rozbil. Napadá mě jediná věc, že tyto iptables-1.4.8-1.5.i586 nespolupracují s tímto jádrem. Snad že bych zkusil nabootovat Knoppix, ručně na něm rozchodit obě síťovky a routování a ručně pustit ten skript. Tím se eliminuje možná chyba distribuce. Je to divný, ale nic jiného mě nenapadá. Je možné, aby tímto způsobem nefungovalo železo?

[vencour]

Pusťte si tam třeba ve screenu watch -d iptables -nvL, pokud se matchne něco, měl byste mít výsledek, pokud nematchne, nastavte jinak pravidla v iptables

[krnoha]

Nemečnulo, ale pravidla jsem nedokázal vylepšit. Nezbylo mi než najít si jiné železo a tam pod Scientific Linuxem můj skript napoprvé fungoval jak má. Potom jsem se vrátil k původnímu železu, nabootoval Kotkův minimax, to je takový live linux z roku 06 a dneska už neudržovaný, skript tam běhal napoprvé. Potom jsem pořád to původní železo nabootoval zase do OpenSuSE 11.3 , firewall funguje a přežil i další rebooty. Protože není možné, aby se software sám takhle spravil, nezbývá mi než si myslet, že se jedná o přechodnou chybu chipsetu. Jádro asi při filtraci paketů spoléhá na nějakou konstrukci, která před týdnem nefungovala a teď zase funguje. A za týden zase nebude, nejspíš. Tímto ten případ uzavírám a už se tím nebudu zabývat.

[vencour]

Ok, (i) jak se píše níže, stavová i nestavová komunikace má jistá pravidla. Stav provozu by měly umožňovat i jisté nástroje ... např. conntrack-tools. Pak byste mohl snad vidět víc ... aneb toto ...

# conntrack
Command line interface for the connection tracking system. Version 0.9.14
Usage: conntrack [commands] [options]

Commands:
  -L [table] [options]          List conntrack or expectation table
  -G [table] parameters         Get conntrack or expectation
  -D [table] parameters         Delete conntrack or expectation
  -I [table] parameters         Create a conntrack or expectation
  -U [table] parameters         Update a conntrack
  -E [table] [options]          Show events
  -F [table]                    Flush table
  -C [table]                    Show counter
  -S                            Show statistics

Tables: conntrack, expect

Conntrack parameters and options:
  -n, --src-nat ip                      source NAT ip
  -g, --dst-nat ip                      destination NAT ip
  -m, --mark mark                       Set mark
  -c, --secmark secmark                 Set selinux secmark
  -e, --event-mask eventmask            Event mask, eg. NEW,DESTROY
  -z, --zero                            Zero counters while listing
  -o, --output type[,...]               Output format, eg. xml

Expectation parameters and options:
  --tuple-src ip        Source address in expect tuple
  --tuple-dst ip        Destination address in expect tuple
  --mask-src ip         Source mask address
  --mask-dst ip         Destination mask address

Common parameters and options:
  -s, --orig-src ip             Source address from original direction
  -d, --orig-dst ip             Destination address from original direction
  -r, --reply-src ip            Source addres from reply direction
  -q, --reply-dst ip            Destination address from reply direction
  -p, --protonum proto          Layer 4 Protocol, eg. 'tcp'
  -f, --family proto            Layer 3 Protocol, eg. 'ipv6'
  -t, --timeout timeout         Set timeout
  -u, --status status           Set status, eg. ASSURED
  -b, --buffer-size             Netlink socket buffer size

by vám mělo umožnit dokázat vic. Tedy pokud komerční firewally dokážou manipulovat s tabulkou spojení apod., proč by to nemohl umět linux dělat ještě líp

[pht]

Aha, já jsem špatně pochopil, že dumpujete na routeru. Tak bych to zkusil tam. Jinak to zní záhadně. Možná že to narušuje nějaké jiné pravidlo.

[VM]

Pozor taky na to, že jádro udržuje tabulku spojení, která mapuje NATové spojení, porty a adresy lokálních strojů. U TCP se to přidává na začátku spojení - takže pokud se spojení otevřelo před přidáním pravidla, tak se nejspíše natovat nebude. Pro natování UDP je nějaká podobná heuristika, která se řídí podle prvního paketu (na tom je založené UDP tunelování dvou sítí za NATem), jak to je s ICMP nevím, ale čekal bych něco podobného. Takže po změně nastavení doporučuji testovat pouze nová TCP spojení.

[rADOn]

mas zapnuty ip_forward?