Policy routing: UDP via verkeerde interface

[Verwijderd]

Om weer een single point of failure weg te halen uit ons bedrijfsnetwerk, heb ik een tweede ADSL lijn in gebruik genomen. Door middel van Policy routing laat ik uitgaande connecties willekeurig via eth0 en eth1 tot stand komen.

Uitgaande TCP verbindingen gaan helemaal prima. Uitgaande UDP verbindingen volgens mij ook, al heb ik daar wel problemen mee gezien. Maar deze krijg ik nu niet meer gemaakt, dus dat lijkt opgelost door de policy te strippen naar het minimum.

Ook inkomende TCP verbindingen gaan zonder problemen. Echter inkomende UDP verbindingen werken veel minder goed: deze gaan via de verkeerde interface terug.

De situatie:

                                                          ________
                                        +-------+        /
                                        |       |       |
                            +-----------+ ISP 1 +-------
        __                  |           |       |     /
    ___/  \_         +------+------+    +-------+    |
  _/        \__      |     eth0    |                /
 /             \     |             |    +-------+   |
| Local network -----+ Linux  eth1 |    |       |   |     Internet
 \_           __/    |             +----+ ISP 2 +---|
   \__     __/       |             |    |       |   \
      \___/          +-------------+    +-------+    |
                                                      \
                             +--------+               /--
                             |        |              /  |
                             + LAPTOP +--------------    \________
                             |        |
                             +--------+

Wanneer de roadwarrior (thuis-/buitenwerker) zijn laptop opstart en een VPN verbinding naar kantoor maakt, wordt er een udp "verbinding" tot stand gebracht: Eerst pakketje 1 van laptop naar router, dan een antwoord van router naar laptop. Maar als pakketje 1 via eth0 binnenkomt, wil het antwoord daarop nogal eens via eth1 terug gaan... en dat kan niet.

Zou het kunnen dat bij TCP (stateful) het source IP voor de hele verbinding geldt, en bij UDP bij ieder pakketje opnieuw beoordeeld moet worden wat het source adres is?

Omdat ik eerst nog dacht dat het misschien wel aan de linux router zelf lag, of aan de kernel, ben 'k vervolgens nog even gaan knoeien met een vmware server, waar 'k de volgende situatie heb gebouwd:

                                                          ________
                                        +-------+        /
                                        |       |       |
                            +-----------+ VMW 3 +-------
        __                  |           |       |     /
    ___/  \_         +------+------+    +-------+    |
  _/        \__      |     eth0    |                /
 /             \     |             |    +-------+   |
|    VMWare 1   -----+ VMW.2  eth1 |    |       |   |     LAN
 \_           __/    |             +----+ VMW 4 +---|
   \__     __/       |             |    |       |   \
      \___/          +-------------+    +-------+    |
                                                      \
                             +--------+               /--
                             |        |              /  |
                             + LAPTOP +--------------    \________
                             |        |
                             +--------+

Hierbij geldt:
VMW1<->VMW2, VMW2<->VMW3 en VMW2<->VMW4 zijn allen afgescheiden VMWare netwerken
VMW3<->LAN en VMW4<->lan zijn gebridged

Hierbij blijkt het resultaat hetzelfde. Op de VMW1 draait een xinetd met echo server. De sniff resultaten zijn als volgt:

vmw3:~# tcpdump -i eth1 not port 53 and udp
vmw4:~# tcpdump -i eth1 not port 53 and udp
laptop:~$ echo dummy|netcat -u 1.1.1.1 echo

resultaat vmw3:
18:33:44.281808 IP 192.168.15.140.1398 > 1.1.1.1.7: UDP, length 5

resultaat vmw4:
18:33:22.948172 IP 2.2.2.1.7 > 192.168.15.140.1398: UDP, length 5

Dus in feite kiest de VMW1 voor een verkeerd source adres voor het retourpakketje.

Een mogelijke oplossing zou zijn al het verkeer voor een bepaalde service maar over 1 poort te routeren, maar dan heb je het oude vertrouwde single point of failure weer terug. Dus da's niet echt een optie.

Een andere oplossing zou zijn: het markeren van het inkomende pakketje mbv iptables [..] -j MARK/CONNMARK, waarbij het antwoordpakketje dezelfde mark zou moeten krijgen. Dan kan je een iproute2 filer plaatsen om het pakketje een bepaalde route op te forceren. Maar dat lukt me niet.

Suggesties? Bij voorbaat dank.

Docu: lartc nano netfilter iproute2

[ Voor 4% gewijzigd door Verwijderd op 06-07-2006 16:45 ]

[daft_dutch]

wat is je iptable script
bij lartc zie ik niks over relaties. ben er nog niet diep in gedoken.
Was dit maar geimplenteerd

Je kan services op 1 ip zetten zonder gevaar van een "single point of failure"
indien je kan controleren of die connectie up is en een dynamische dns gebruiken die naar de werkende ip wijst.

IP1 is standaard maar faalt. IP2 neemt het over en veranderd de dns zodat die naar IP2 wijst.
mischien is dit een tijdelijke oplossing.

[Verwijderd]

Thanks voor de reactie en suggestie!

Het gebruikte iptables script is heel eenvoudig:

iptables -t nat -I POSTROUTING -o eth0 -j SNAT --to-source 1.1.1.1
iptables -t nat -I POSTROUTING -o eth0 -j SNAT --to-source 2.2.2.1

oftewel: uitgaand traffic over beide interfaces met het juiste ipadres SNAT'ten.

DNS zou ook kunnen, maar dan heb je inderdaad een actief deel op je dns server nodig. Plus dat de DNS oplossing natuurlijk alleen werkt tegen uitval, niet voor load-balancing.

Hoewel de lartc how-to toch in nieuwsgroepen/forums/etc als belangrijkste bron wordt genomen voor dit onderwerp, lijkt de methode die daar toegepast wordt de problemen te veroorzaken:

ip route add $P1_NET dev $IF1 src $IP1 table T1
ip route add default via $P1 table T1
ip route add $P2_NET dev $IF2 src $IP2 table T2
ip route add default via $P2 table T2

Bij Nano had ik over een interessant stukje heen gelezen. Als ik de bovenstaande commando's van lartc vervang door dit commando, lijkt het probleem opeens verholpen:

ip rule add prio 50 table main

Op dit moment is het midden op de werkdag, en dan mag ik van de baas geen storingen veroorzaken (lullig he ). Maar vanavond ga ik kijken hoe de échte gateway server hierop reageert.

[Verwijderd]

Nou, ik heb de afgelopen dagen nog wat gespeeld, maar echt niet werken he.

In de simulatie leek bovenstaande oplossing te werken... maar daar had ik alleen getest met de eenvoudiger programma's, zoals netcat. In de live omgeving blijkt het niet te lukken. En ga ik in de test-omgeving met programma's als openvpn werken, dan blijken de problemen van de live omgeving daar net zo goed voor te komen: uitgaande udp pakketjes (replies) gaan gewoon iedere keer via de verkeerde interface.

Wat kan ik hier nog tegen doen?

[Guru Evi]

UDP pakketjes zijn imho nog steeds stateless. Dat betekent dat de firewall niet bijhoudt waarvan het pakketje komt en dus komt het uit de interface met de standaard route naar buiten (waarschijnlijk eth0 voor jou) ipv. de interface die gebruikt werd om binnen te komen.

Dat het niet werkt, is een verkeerd gebruik van het UDP protocol en/of een slechte afhandeling van je UDP pakketjes in je programma.

[nzyme]

DNS als vorm van loadbalancing is toch juist in opkomst ? En lijkt me dat je dat hier toch ook best moet kunnen toepassen... Je kan immers met 2 ip's je eigen dns draaien (2ip's == 2 hosts == eigelijk niet tegelijk down == altijd beschikbare dns).