Souvislost ip_conntrack_tcp_timeout_established s DNATem

2.3.2009 16:15 | Přečteno: 1130× | GNU/Linux | poslední úprava: 3.3.2009 15:06

Děkuji všem za pomoc, problém již považuji za vyřešený.

Dovoluji si zneužít blog pro jistý dotaz (a související brainstorming). Zjistil jsem, že SSH spojení přesměrované pomocí DNATu do DMZ po zhruba 20 minutách neaktivity zamrzne. Tento problém jsem lokalizoval na ADSL router (nějaký starý Linux) a jeho conntrack, který má nastaveno ip_conntrack_tcp_timeout_established na 1200 sekund. Není mi ovšem jasné, proč je jeho conntrack v tomto případě vůbec relevantní, když přesměrování je nastaveno přes DNAT v řetězci PREROUTING.

Nastavení iptables přikládám:

# iptables -L -n -v
Chain INPUT (policy ACCEPT 69481 packets, 4188K bytes)
 pkts bytes target     prot opt in     out     source               destination         
15616  911K CFG        tcp  --  *      *       10.0.0.254           0.0.0.0/0          tcp dpt:80 Records Packet's Source Interface 

    0     0 CFG        tcp  --  *      *       10.0.0.254           0.0.0.0/0          tcp dpt:443 Records Packet's Source Interface 

   89 17248 ACCEPT     all  --  ppp0   *       0.0.0.0/0            0.0.0.0/0          state RELATED,ESTABLISHED 
  546 15288 ACCEPT     icmp --  ppp0   *       0.0.0.0/0            0.0.0.0/0          icmp type 8 state NEW 
  977  126K DROP       all  --  ppp0   *       0.0.0.0/0            0.0.0.0/0          

Chain FORWARD (policy ACCEPT 557K packets, 62M bytes)
 pkts bytes target     prot opt in     out     source               destination         
 713K  764M ACCEPT     all  --  ppp0   *       0.0.0.0/0            0.0.0.0/0          state RELATED,ESTABLISHED 
 7349  441K ACCEPT     tcp  --  ppp0   *       0.0.0.0/0            10.0.0.254         tcp dpt:22 
    3   180 ACCEPT     tcp  --  ppp0   *       0.0.0.0/0            10.0.0.254         tcp dpt:465 
    5   300 ACCEPT     tcp  --  ppp0   *       0.0.0.0/0            10.0.0.254         tcp dpt:993 
    2   120 ACCEPT     tcp  --  ppp0   *       0.0.0.0/0            10.0.0.254         tcp dpt:995 
  133  7164 ACCEPT     tcp  --  ppp0   *       0.0.0.0/0            10.0.0.254         tcp dpt:5269 
   13   780 ACCEPT     tcp  --  ppp0   *       0.0.0.0/0            10.0.0.254         tcp dpt:5222 
    4   240 ACCEPT     tcp  --  ppp0   *       0.0.0.0/0            10.0.0.254         tcp dpt:5223 
   31  1672 ACCEPT     tcp  --  ppp0   *       0.0.0.0/0            10.0.0.254         tcp dpt:25 
    6   340 ACCEPT     tcp  --  ppp0   *       0.0.0.0/0            10.0.0.254         tcp dpt:443 
  457 27056 ACCEPT     tcp  --  ppp0   *       0.0.0.0/0            10.0.0.254         tcp dpt:80 
17792 1066K TCPMSS     tcp  --  *      ppp0    0.0.0.0/0            0.0.0.0/0          tcp flags:0x06/0x02 TCPMSS clamp to PMTU 
    0     0 DROP       all  --  ppp0   *       0.0.0.0/0            0.0.0.0/0          

Chain OUTPUT (policy ACCEPT 67850 packets, 8572K bytes)
 pkts bytes target     prot opt in     out     source               destination         
11029 1213K DROP       icmp --  *      ppp0    0.0.0.0/0            0.0.0.0/0          icmp type 3 
    1    56 DROP       icmp --  *      ppp0    0.0.0.0/0            0.0.0.0/0          state INVALID

A ještě tabulka nat:

# iptables -t nat -L -n -v
Chain PREROUTING (policy ACCEPT 40082 packets, 2518K bytes)
 pkts bytes target     prot opt in     out     source               destination         
 7349  441K DNAT       tcp  --  ppp0   *       0.0.0.0/0            0.0.0.0/0          tcp dpt:22 to:10.0.0.254:22 
    3   180 DNAT       tcp  --  ppp0   *       0.0.0.0/0            0.0.0.0/0          tcp dpt:465 to:10.0.0.254:465 
    5   300 DNAT       tcp  --  ppp0   *       0.0.0.0/0            0.0.0.0/0          tcp dpt:993 to:10.0.0.254:993 
    2   120 DNAT       tcp  --  ppp0   *       0.0.0.0/0            0.0.0.0/0          tcp dpt:995 to:10.0.0.254:995 
  133  7164 DNAT       tcp  --  ppp0   *       0.0.0.0/0            0.0.0.0/0          tcp dpt:5269 to:10.0.0.254:5269 
   13   780 DNAT       tcp  --  ppp0   *       0.0.0.0/0            0.0.0.0/0          tcp dpt:5222 to:10.0.0.254:5222 
    4   240 DNAT       tcp  --  ppp0   *       0.0.0.0/0            0.0.0.0/0          tcp dpt:5223 to:10.0.0.254:5223 
   31  1672 DNAT       tcp  --  ppp0   *       0.0.0.0/0            0.0.0.0/0          tcp dpt:25 to:10.0.0.254:25 
    6   340 DNAT       tcp  --  ppp0   *       0.0.0.0/0            0.0.0.0/0          tcp dpt:443 to:10.0.0.254:443 
  458 27116 DNAT       tcp  --  ppp0   *       0.0.0.0/0            0.0.0.0/0          tcp dpt:80 to:10.0.0.254:80 

Chain POSTROUTING (policy ACCEPT 15861 packets, 961K bytes)
 pkts bytes target     prot opt in     out     source               destination         
37691 2325K MASQUERADE  all  --  *      ppp0    0.0.0.0/0            0.0.0.0/0          

Chain OUTPUT (policy ACCEPT 14 packets, 990 bytes)
 pkts bytes target     prot opt in     out     source               destination

Pokud si to správně pamatuji, tcpdump odhalil, že keep alive pakety jdou nejprve zevnitř sítě ven, ale na vnější stroj se nedostanou. Poté začne keep alive pakety vysílat vnější stroj, ale domů se nedostane (to je mi jasné, paket přijde na vyšší port, a protože chybí conntrack záznam, firewall ho zahodí). Ale proč neprojdou keep alive pakety zevnitř ven, když směřují na 22 a firewall navíc FORWARD nijak ve směru zevnitř ven neomezuje, to mi jasné není. Druhý firewall v síti také neomezuje provoz z DMZ ven, proto jej ani neuvádím jako relevantní.

Za zneužití blogu tímto způsobem se předem omlouvám, ale poradnu bych tím zneužívat nechtěl. Není to problém, který potřebuji vyřešit, spíše bych rád pochopil, proč k tomu dochází. Přemýšlím o tom už několikátý den a stále na to nemohu přijít. Za odpovědi předem děkuji.

Dodatek první: Problém nastává jak v situaci, kdy se klient připojuje zvenčí k SSH serveru v DMZ, tak v situaci, kdy se stroj v DMZ připojuje jako klient k SSH serveru venku.

Dodatek druhý: Jak mne správně upozornil petr_p, délku uchování záznamu o navázaném spojení v conntrack tabulce určuje parametr ip_conntrack_tcp_timeout_established, nikoliv ip_conntack_max, jak jsem uvedl v blogpostu. Hodnota 1200 se tedy skutečně týká ip_conntack_tcp_timeout_established, nikoliv ip_conntrack_max, tj. záznam v conntrack tabulce ADSL routeru o vytvořeném spojení skutečně vyprší po 20 minutách neaktivity. Omlouvám se za mystifikaci.

Dodatek třetí: Problém zmizí, pokud aktivuji DMZ na ADSL routeru, což provede následující změny ve firewallu. Poslední pravidlo pro řetězec FORWARD se změní z DROP na:

0     0 ACCEPT     all  --  ppp0   *       0.0.0.0/0            10.0.0.254     

A v tabulce nat, řetezci PREROUTING se přidají dvě pravidla:

0     0 DNAT       all  --  ppp0   *       0.0.0.0/0           !veřejná_ip      to:0.0.0.0
0     0 DNAT       all  --  ppp0   *       0.0.0.0/0            veřejná_ip      to:10.0.0.254

Dodatek čtvrtý: Průběh celé akce.

• spojení je navázáno (klient - router1 - ADSL router - NET - server)
• ADSL router má záznam v conntrack tabulce:

  tcp      6 1199 CoS6 ESTABLISHED src=klient dst=server sport=59918 dport=22 src=server dst=verejna_ip sport=22 dport=59918 use=1

• za 20 minut záznam v conntrack tabulce ADSL routeru vyprší (díky ip_conntrack_tcp_timeout_established=1200)
• klient se snaží pokračovat v navázané komunikaci a vysílá pakety:

  20:11:13.108303 IP klient.59918 > server.22: P 1841:1889(48) ack 2926 win 757 <nop,nop,timestamp 75970738 1061777273>

• pakety nedorazí na server, ADSL router je patrně zahodí (jak to?)
• klient timeoutuje
• server vysílá keep alive pakety, které ADSL router zahodí, protože přicházejí na nepřesměrovaný, vyšší port, a ADSL router již nemá v conntrack tabulce záznam o tomto spojení (to je mi jasné)
• server timeoutuje

Je tedy jasné, že problém je ve firewallu ADSL routeru, ale kde, to netuším.

Dodatek pátý: Asi už to mám. Samozřejmě opravte mne, pokud se mýlím.

       

Anketa

Komentáře

[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í.