Dual NIC, problem s nedostupnosti

[Dan Lukes]

On 27.3.2009 14:51, Lubos Dolezal:
> Narazil jsem na mozna "zajimavy" problem u sitovani na 7.1-RELEASE (amd64).
> Server ma dve sitova rozhrani pripojena v rozdilnych sitich (bge0, bge1):
> ---
> defaultrouter="172.25.11.1"
> bge0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
> inet 172.25.11.23 netmask 0xffffff00 broadcast 172.25.11.255
> bge1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
> inet 172.25.9.12 netmask 0xffffff00 broadcast 172.25.9.255

> Ted k tomu "problemu". Pokud je rozhrani "bge1" aktivni (a
> nakonfigurovane na uvedenou adresu) nelze se z jineho serveru v siti
> "172.25.9.0/24" dostat na sitove sluzby bezici na adrese 172.25.11.23
> (rozhrani bge0). Napr. z 172.25.9.10:
> ---
> $ telnet 172.25.11.23 22
> Trying 172.25.11.23...
> telnet: Unable to connect to remote host: Connection timed out


Jen aby nam tu nezustali neuzavrene problemy, kdyz je reseni znamo.

Nakonec stacilo poridit tcpdumpem zaznam komunikace z obou koncu. 
Ukazalo se, ze pakety neprichazeji tak, jak byly odeslany. Uvodni SYN 
packet dorazi na server z odlisnymi sekvencnimi cisly nez s jakymi byl 
odeslan z klienta. No a to je cela potiz.

SYN+ACK odeslany v opacnem smeru mel hodnotu ACK odpovidajici tomu, co 
na server dorazilo - a protoze "zpetky" paket sel primo, nikoliv pres 
router, dorazil v tomto smeru paket nezmeneny. Klientovi hodnota ACK 
nesedela k sekvencnimu cislu, se kterym on SYN odeslal a tudiz dospel k 
zaveru, ze se nejedna o odpoved na jeho paket. Reagoval proto zaslanim 
RST. Spojeni se pochopitelne nesestavilo.

Zbyvalo najit, kdo meni sekvencni cisla a to uz bylo trivialni - po 
ceste je CISCO a na nem ASA/PIX. A to defaultne pocita s tim, ze sitove 
stacky systemu nejsou bezpecne napsane a sekvencni cisla posouva o 
nahodne zvoleny offset aby se nikomu ISN nepodarilo uhadnout. Pokud jde 
komunikace zpatky pres nej, je to v pohode (hodnoty ACK posouva o stejny 
offset zpet), pokud ne, jako v tomto pripade, smula.

Bohuzel, ani vypnuti randomizace pro komunikaci mezi temito vnitrnimi 
sitemi problem nevyresilo, protoze firewall nevidi kompletni handshaking 
(kdyz jeden smer pres nej nejde) a nema tudiz spojeni za ustavene a 
odmita propustet data.

Podle me je snadne reseni i tady (proste mu jakekoliv filtrovani teto 
komunikace zakazat uplne - u stroju, ktere maji nezavisle prime spojeni 
to stejne nema bezpecnostni smysl), ale jestli se Lubos rozhodne pro 
toto reseni, nebo zustane u workaroundu, ktery uz zvolil (pomoci pf 
tlaci "zpetne" pakety take pres router), to je vic politicka nez 
technicka otazka a to uz je ciste na nem.

Jinymi slovy, puvodne poskytnuta informace, ze firewall tuto komunikaci 
neblokuje se ukazala nebyt uplne presna. Sice neblokoval, ale nevhodne 
ovlivnoval - a kdyz se mu to zatrhlo, tak teprve tehdy zacal natvrdo 
blokovat ;-)


							Dan