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 :(
- 1075 megtekintés
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 hozzászóláshoz be kell jelentkezni
A XenServer lesz itt a ludas. Megcsináltam ugyanezt egy VMware ESXi-n is és ott vígan megy.
- A hozzászóláshoz be kell jelentkezni
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)
- A hozzászóláshoz be kell jelentkezni