Souvislost ip_conntrack_max s DNATem (diskuse)

[petr_p]

Dvě chyby:

Odpovědi z SSH serveru se nevracejí přes natující stroj, takže ten neaktualizuje conntrack záznam a časem vyprší.

ip_conntrack_max neurčuje životnost záznamu v sekundách, ale velikost conntrack tabulky. To jest kolik záznamů se do tabulky najednou vejde. Když se zaplní, tak si začne jádro stěžovat a nová spojení nebude přidávat.

[pasmen]

Hmm, jakto že se nevrací odpovědi z SSH serveru přes NATující stroj? Pokuď by se nevraceli tudy, pak by vůbec nedošlo k navázání spojení s tím serverem ne?

[petr_p]

Pravda. Nějak mě rozhodila jeho tabulka nat, protože jsem ještě neviděl, aby někdo přesměrovával libovolný provoz na vybraných portech bez ohledu na cílovou adresu na jediný stroj. Tam to asi bude divoký, když DMZ má neveřejné adresy :(

[Shadow]

Divoké to je. Dodávám, že ten firewall jsem nevymyslel já, ten vymyslel výrobce Well PTI-845. Bohužel s tím firewallem nic moc neudělám, přenastavit ho sice můžu, ale jen do příštího rebootu routeru. Totéž se týká nastavení jádra. Mohu leda přesměrovat veškerý provoz na druhý router za tím, což jsem z hlediska bezpečnosti dělat nechtěl. No, uvidím.

Nicméně, asi jsem na to přišel, díky vašemu jinému příspěvku. Jakmile zmizí z conntrack tabulky záznam o vytvořeném spojení, vyleze z maškarády následný paket s nezměněnou (lokální) zdrojovou adresou, takže ho po cestě nejspíš zahodí nějaký jiný router. Pokud se v této hypotéze nemýlím, je to odpověď, kterou jsem hledal, děkuji moc.

[pasmen]

Pokud tomu rozumím správně, tohle není pravda ze dvou důvodů:

• Maškarádují se všechny datagramy bez vyjímky, to je podstata maškarády. Conntracková tabulka je akorát přiřazuje ke spojením.
• Pokud se nějaký datagram zahodí, pak dojde k znovyvyslání. Tedy za předpokladu, že jde o TCP, což v případě SSH jde.

[Shadow]

No, když jsem používal CDMA, modem měl takovou úžasnou vlastnost, že ukončil spojení, pokud na jeho rozhraní přistál paket s jinou zdrojovou adresou než je místní adresa onoho rozhraní. A dost dlouho jsem řešil právě to, že ač tam byla maškaráda (-o ppp0 -j MASQUERADE), přesto na tom rozhraní končily pakety s jinou zdrojovou adresou, čímž došlo k ukončení spojení. No a to se dělo tak často, že ani automatické znovunahození spojení z toho neudělalo použitelné připojení. A to byly mj. pakety, ke kterým conntrack ztratil stav. Nakonec jsem lehkým hackem iptables dospěl k sadě pravidel, která úspěšně INVALID pakety s -o ppp0 prostě zahazovala.

Také to může být nějaká chyba v netfilteru, na ADSL routeru je ještě jádro řady 2.4, čili i to je alternativa.

Pokud se nějaký datagram zahodí, pak dojde k znovyvyslání. Tedy za předpokladu, že jde o TCP, což v případě SSH jde.

Ano, k tomu skutečně dochází, vnitřní stroj posílá pakety na vnější stroj, ale ty pakety tam prostě nedorazí. Žádný z nich. Zahazuje je něco na cestě. A to ihned po tom, co ADSL router vymaže záznam o daném ESTABLISHED spojení z conntrack tabulky. Čili, buď je zahazuje ADSL router (ale není mi jasné, jakým pravidlem), nebo nějaký router za ním, ovšem ten by zahodil asi jenom paket s jinou zdrojovou adresou než je veřejná IP přidělená ADSL routeru. Ale to nevím jistě, routery O2 nemám pod svou správou (zatím).

[petr_p]

Maškarádují se všechny datagramy bez vyjímky, to je podstata maškarády. Conntracková tabulka je akorát přiřazuje ke spojením.

Ne. Linuxový NAT je plně stavový, co není v tabulce spojení, se pro jistotu nepřekládá. Do tabulky spojení se záznam uloží „jen“ při prvním packetu ze spojení.

MASQUERADE se od SNAT liší v tom, že sleduje adresu rozhraní a při jejím smazáním odstraní všechna spojení překládaná na tuto adresu.

[pasmen]

Aha, díky.

[Shadow]

Děkuji za odpověď.

ad ip_conntrack_max)

Možná jsem to zvoral a zaměnil ip_conntrack_max a ip_conntrack_tcp_timeout_established, ale to se budu muset podívat a přístup do DMZ teď nemám (jako na potvoru teď vypadlo DSL, takže se k routeru nedostanu). Prověřím to, jakmile budu mít příležitost, a když tak aktualizuji blogpost.

ad odpovědi z SSH serveru)

SSH komunikace normálně prochází, spojení je po navázání aktivní, data procházejí tam a zpět. Takže buď to není ten případ, nebo zase něčemu nerozumím. Dodám ještě, že problém se týká nejen připojení zvenčí na SSH server v DMZ, ale také připojení z DMZ na SSH servery venku.

[Shadow]

Blogpost aktualizován, 20 minut (alias 1200 sekund) se skutečně týká ip_conntrack_tcp_timeout_established a nikoliv ip_conntrack_max, jak jsem mylně uvedl, omlouvám se.

[Grunt]

Abych pravdu řekl, tak jsem vůbec nepochopil o co ti vlastně jde, ale snad to zachrání pár citací:

 

Connection Tracking - Description

 

Connection tracking refers to the ability to maintain the state information about connections, such as source and destination IP address and ports pairs, connection states, protocol types and timeouts. Firewalls that do connection tracking are known as "stateful" and are inherently more secure that those who do only simple "stateless" packet processing.
…

Connection tracking is done in the prerouting chain, or the output chain for locally generated packets.

Another function of connection tracking which cannot be overestimated is that it is needed for NAT. You should be aware that no NAT can be performed unless you have connection tracking enabled, the same applies for p2p protocols recognition. Connection tracking also assembles IP packets from fragments before further processing.
…

 

Connection Timeouts

 

Connection tracking provides several timeouts. When particular timeout expires the according entry is removed from the connection state table. The following diagram depicts typical TCP connection establishment and termination and tcp timeouts that take place during these processes:
…

tcp-established-timeout (time; default: 1d) - maximal amount of time connection tracking entry will survive after having seen an acknowledgment (ACK) from connection initiator
…

[Shadow]

Šlo mi o to, proč po vypršení záznamu o SSH spojení v conntrack tabulce ADSL routeru dojde k jeho zamrznutí a následné pakety se nedostanou zevnitř DMZ přes ADSL router na cílovou stanici (proč to nešlo v opačném směru mi bylo jasné). Teď už je mi jasné i toto, a je to popsáno i v tom, co jsi tu citoval. Jakmile vyprší conntrack záznam v tabulce ADSL routeru, tak nezávisle na DNATu, který je na něm nastavený, router už neprožene příslušné pakety maškarádou, takže se ven dostanou pakety s lokální zdrojovou adresou, které zahodí routery za ním.

Čili, souvislost s DNATem (resp. přesměrováním portů) tu není, je to pouze problém maškaráda versus conntrack. Ještě mi sice není úplně jasné, proč k problému nedojde v situaci popsané v dodatku tři, ale to si už vyřeším sám. Děkuji všem za pomoc a problém považuji za vyřešený.

[Grunt]

NAT se dělí na SNAT a DNAT(Source NAT a Destination NAT) a podle toho se přepisuje buď cílová a nebo zdrojová adresa. A maškaráda není nic jiného než SNAT který za zdrojovou adresu automaticky dopisuje adresu rozhraní ze kterého bude paket vycházet. Žádný šotek a nebo černá magie v tom není.