SYN+ACK nem talál haza

Linux-haladó

A következőbe futottam bele, és egyenlőre nem tudok rá racionális magyarázatot adni:
Ubuntu 12.04, kernel a hozzá adott 3.2.0-26-generic x86_64
A gépnek van 3 felhúzott hálózati interfésze: tun0, tun1, eth0 (a két tun az eth0-n megy keresztül).
A tun0 IP címe 10.5.x.x, a tun1-é 10.8.x.x, az eth0 192.168.1.4. A két tun-t szolgáltató szerverek fel vannak véve a routing táblába, valahogy így:
route add a.b.c.d gw 192.168.1.1
route add e.f.g.h gw 192.168.1.1
A default gw a tun1-re mutat. Eddig minden működik szépen.

van egy szolgáltatás, aminek nem kellene átmennie a tun1-en, hanem egyből a 192.168.1.1-en keresztül kellene elérnie e netet. Mivel ez user1 nevében fut, gondoltam megcsinálom így:
- A mangle táblában rakok egy fwmark 0x10 -et vagy TOS 0x10-et a user1 csomagjaira
- ip route -tal létrehozok egy táblát, ahol a default gw az eth0-n keresztül a 192.168.1.1
- ip rule -al létrehozok egy szabályt, hogy fwmark 0x10 vagy TOS 0x10 csomagok ez szerint az új tábla szerint menjenek.

Kipróbáltam (mind fwmark-kal, mint TOS-sal): user1-ként kiadva tesztként, hogy telnet -b 192.168.1.4 index.hu 80 a következőt láttam a tcpdump-ban:
- A SYN csomag szépen elment a 192.168.1.4 -es IP-ről eth0-n keresztül 192.168.1.1-es gw felé
- A távoli gép küldi a SYN+ACK-ot a 192.168.1.4-nek, ahogy kell (nyilván a 192.168.1.1.es gw-en keresztül, eth0-n esik be)
- A /proc/net/ip_conntrack szerint a a kapcsolat átvált SYN_SENT -ből SYN_RCVD -be
- A network socket viszont sosem kapja meg a SYN+ACK-ot, a netstat szerint elakad a handshake 1. lépésénél. Egy idő után megpróbálja megint elküldeni a SYN-t, persze megint pont ugyan így jár.

A problémát megoldottam végül úgy, hogy kiszedtem a fwmark-os netfilter szabályt, a szolgáltatást bindoltam egy dummy IP-re, az ip rule-t kicseréltem, hogy fwmark helyett source IP alapján válasszon táblát + raktam egy SNAT-ot, hogy a dummy IP-t kicseréljem 192.168.1.4- re a kimenő csomagoknál, és így most működik szépen.

Hogy miért nem működött az eredeti elképzelés, azt továbbra sem értem. Eszközt sem tudok mondani hirtelen, amivel végig lehetne követni, hogy miért nem találkozik a megérkezett SYN+ACK csomag a sockettel.

  • 2209 megtekintés

( dap | 2012. 08. 06., h – 01:11 )

Túl fáradt vagyok ahhoz, hogy ezt most felfogjam, tippelek: nem az rp_filter kavar be? A bekapcsolt log_martians nem beszél?

( hrgy84 | 2012. 08. 06., h – 02:09 )

route add -host a.szolgaltatas.ip.cime 192.168.1.1

Es akkor nem a tun-ok fele routol.

De egyebkent mindenki utalja a szoveges feladatokat, szoval tessek iptables-save, ip route, ip rule, meg hasonlo dumpokat nyomkodni, es pasztazni. Ha hosszu, akkor pastebinre.

Illetve nem ertem ezt: "miért nem találkozik a megérkezett SYN+ACK csomag a sockettel." Most akkor megjon vagy nem jon meg? Elotte azt irod, hogy valasz nem jon. Ha megjonne az ACK, akkor az tuti talalkozna a sockettel.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

"route add -host a.szolgaltatas.ip.cime 192.168.1.1
Es akkor nem a tun-ok fele routol."

Feltéve, hogy a szolgáltatást külön IP-ra bindoltad. Különben meg arra megy az is, aminek nem kéne.

"lletve nem ertem ezt: "miért nem találkozik a megérkezett SYN+ACK csomag a sockettel." Most akkor megjon vagy nem jon meg? Elotte azt irod, hogy valasz nem jon. Ha megjonne az ACK, akkor az tuti talalkozna a sockettel."

Ezt nem értem én sem, ez lett volna a kérdés. A SYN+ACK csomag eljut a hálókártyáig, a tcpdump mutatja, a /proc/net/ip_conntrack szerint a a kapcsolat átvált SYN_SENT-ből SYN_RCVD-be. A netstat viszont azt mutatja, hogy a socket még mindig a handshake első fázisában van, és néhány másodperc múlva megint küld egy SYN-t, szóval tényleg ott van.

( vl v | 2012. 08. 06., h – 06:23 )

A normál routing táblába (main) nem raksz default route-ot.
A "default" nevűbe rakod azokat a szabályokat, amik most a default route-odat adják.
Csinálsz per kimenő hálózat egy-egy tablát, amiben csak az odatartozó default route szerepel (net1, net2,...). Az fwmark1.. részt értelemszerűen kell kitölteni.

Ha valamelyik default route-od dinamikus (a tunosok nyilván azok), akkor a lenti kódban kell hozzá a prio 250 unreachable szabály, hogy a már forráscímmel rendelkező forgalmat ne küldjed ki másik hálózaton, ha elmúlik a hozzá tartozó default route.

LOCALNETS="127.0.0.0/8 192.168.1.0/24 10.5.0.0/16 10.8.0.0/16"

ip rule flush
ip rule add from all priority 32766 table main
ip rule add from all priority 32767 table default

for net in $LOCALNETS; do
ip rule add to $net priority 100 table main
ip rule add from $net priority 100 table main
done

ip rule add from 192.168.1.4 priority 200 table net1
ip rule add from 10.5.x.x priority 200 table net2
ip rule add from 10.8.x.x priority 200 table net3

ip rule add from 10.5.x.x priority 250 unreachable
ip rule add from 10.8.x.x priority 250 unreachable

ip rule add fwmark mark1 priority 300 table net1
ip rule add fwmark mark2 priority 300 table net2
ip rule add fwmark mark3 priority 300 table net3

Nem arra vagyok kíváncsi, hogy hogyan lehet másképp megoldani, mert az sikerült, ahogy írtam is. Arra vagyok kíváncsi, hogy az eth0-n megjelenő SYN+ACk csomag (az előtte levő switch + a gépen futtatott tcpdump alapján ott a csomag) hogyan nem képes a socketet átlökni a handshake második fázisába, mikor még az ip_conntrack szerint is át kellene kerülnie.