Xen VM - NAT + IPVS [megoldva]

IP Virtual Servert próbálok felkonfigolni. Próbálkoztam több elv szerint, de sehogy sem akar menni.

Az eth0 publikus IP-je mögött szeretnék 2db szervert futtani, melyek eth1-re kapcsolódnak privát IP tartományon.

ldirectord.cf:

virtual=194.88.xxx.xxx:80
real=172.21.42.41:80 masq
real=172.21.42.42:80 masq
fallback=127.0.0.1:80 gate
service=http
request="ldirector.html"
receive="Test Page"
scheduler=wlc
protocol=tcp
checktype=negotiate

iptables -t nat -L:

Chain POSTROUTING (policy ACCEPT)
target prot opt source destination
MASQUERADE all -- 172.21.42.0/24 anywhere

Ezesetben mindkét if-en látom jönni-menni a csomagokat (HTTP GET, 200 OK), de a kliensre már mégsem érkeznek meg.
Gyanítom, hogy mivel a kliens is NAT mögött van, a visszatérő csomagok nem találnak be a kliensre, mert valahol elveszik a csomag azonosító - legalábbis más ötletem nincs, ezt viszont nem tudom ellenőrizni, mert ahhoz a routerhez nem férek hozzá :(

Szerintetek?

------
B terv

Megpróbáltam felvenni egy privát IP-t a router belső if-ére, majd ezt küldöm IPVS-el a belső szerverekre.

ldirectord.cf:

virtual=172.21.42.140:80
real=172.21.42.41:80 gate
real=172.21.42.42:80 gate
...

Ez a megoldás viszont már ott megbukik, hogy a routeren lynx-el tesztelve a belső szerverek felé a publikus (194.88.xxx.xxx) forrás IP-vel mennek a csomagok, így a válaszok már ide sem találnak vissza.
Miért ez a forrás IP? Ezek a csomagok eth1-en mennek ki, annak semmi közze ehhez az IP-hez (ez az eth0 IP-je). Adott if-en kimenő csomagoknak nem az adott if elsődleges IP-jével kéne kimenniük, mint forrás IP?

Valaki világosítson meg, mert reggel óta ezzel szenvedek :(

Hozzászólások

Valami más sz@* lesz a palacsintában :(

Mindez egy Xen VM-en fut. Ugyanazon gépen a szomszéd VM-ról elérhető az oldal a publikus if-eken, publikus IP-ken keresztül, viszont már ugyanabból az IP tartományból más külső gépről sem.
A XenServer szűrhet valamit a hálókártyákon?

A XenServer lesz itt a ludas. Megcsináltam ugyanezt egy VMware ESXi-n is és ott vígan megy.

Ha valaki belefutna hasonló problémába, én 3 nap szívás után találtam rá erre a leírásra.
Bár eszerint a probléma csak akkor áll fent, ha az LVS director és a "realserver" közös Xen hoston van, de ennek ellenkezőjét már nem volt energiám/lehetőségem leellenőrizni. Checksum kikapcsolva (csak a "realserver" eth if-én) és megy.

Bónusz kérdés: Milyen problémákat vethet fel később a checksum kikapcsolása? (Amúgy alapbeállításban ezeken az if-eken csak tx checksum volt bekapcsolva, az rx nem)