Xen virtuális hálózat

Hálózati eszközök

Tisztelt hozzáértők!

Segítséget szeretnék kérni a hálózat konfigurációjához. VPN-en keresztül csatlakozunk a cég hálózatához, 192.168.252.X ip címeket kapunk. A jelenlegi - fizikai - fejlesztői szervereink IP címének a vége 253.X.  Az internet felé elérhető pár szerverünk, ezek a 255-ös körön (is és a 253-ason is) vannak.

A tűzfal úgy van beállítva, hogy a 252-es körről látjuk a 253-ason lévő IP-ket (ha nem kör a hivatalos neve, akkor bocsánat, eddig nem kellett ilyennel foglalkoznom), de a 255-öseket nem. A 253-as kör szerverei "átlátnak" a 255-ös körbe.

Minden rendben is volt, de nemrég kaptunk egy új szervert, és felmerült, hogy virtualizáljunk, amihez a Xen-t választottuk. A szerveren két interface van, az egyiket a 253-as, a másikat a 255-ös körre konfiguráltam Bridge segítségével:

cat /etc/network/interfaces

auto eth0
iface eth0 inet manual

auto xenbr1
iface xenbr1 inet static
 bridge_ports eth0
 address 192.168.253.102
 netmask 255.255.255.0
 gateway 192.168.253.254

auto eth1
iface eth1 inet manual

auto xenbr0
iface xenbr0 inet static
 bridge_ports eth1
 address 192.168.255.188
 netmask 255.255.255.0
 gateway 192.168.255.254

A fejlesztői virtuális gépünkbe két hálózati interfészt tettem, ezeket a fenti két bridge-elt interfészre "kötöttem", így elérem a 253-as és a 255-ös kör IP-it. Viszont VPN-ről nem tudok kapcsolódni a virtuális gép 253-as körű IP-jére, az SSH timeout-tal elszáll. Ha egy, a 253-as kör szerveréről ssh-zom a virtuális gépre, az működik.

Mit tegyek, hogy VPN-ről elérhető legyen a 253-as körön lévő virtuális szerver? Szinte száz százalék, hogy nem a tűzfalunkkal van gond, hanem valamelyik virtuális beállítással.

Próbálkoztam VLAN létrehozásával az új szerveren, sok kombinációval, de nem jártam sikerrel.

Köszönöm a válaszokat!

  • 174 megtekintés

( x-daemon | 2021. 03. 17., sze – 18:09 )

Szerkesztve: 2021. 03. 17., sze – 18:34

hozzal letre networking interfeszeket

pl.:

ha a 252-es subnet a 252-es vlant hasznalja akkor egy 252-es vlanosat

es

ha a 253-es subnet a 253-as vlant hasznalja akkor egy 253-as vlanosat

es

ha a 255-es subnet a 255-os vlant hasznalja akkor egy 255-os vlanosat

arra a nic-re amit a switch olyan portjaba dugsz bele amire be van allitva mindharom vlan

a guesteknek mindig azt a networking interfeszt allitsd be amelyik az ip cimenek megfelelo, amelyik subnebe tartozik

a host halozatanak ehhez nincs koze, hasznalhatod ra a fenti 3 networking interfesz kozul barmelyiket vagy egy vlan nelkuli interfeszt is a masik nicen ahogy most is van.

neked aztan fura humorod van...

( Zs | 2021. 03. 18., cs – 11:05 )

Az én gyanúm az, hogy routing probléma van. A VPN-ből a csomag a .253-as subnetből csöppen a VM-be. A VM viszont benne van mind a .252-es, mind a .255-ös lanban. Logikusan a default gw a .255-ös LAN-ban lesz - tehát ha nincs extra route a VM-ben felvéve, hogy "de a .253-as LAN-t a .252-es GW-n keresztül látod", akkor a válasz csomagok a .255 lan-ba lógó lábon lépnek ki, annak az IP címével. Ez persze azt eredményezi, hogy a VPN kliens szól egy adott IP címnek és egy másikról jön a válasz. Legyünk őszinték: nem erre fog számítani.

Az elméletet tcpdump barátoddal ellenőrizheted: melyik lábon mi jön be, mi megy ki, ami kimegy, az a megfelelő lábon a megfelelő forrás IP-vel indul el? Mivel jó eséllyel szép forgalmad lesz, azért ajánlom a filtereket, pl. a csomagban vagy a forrás- vagy a cél IP legyen az VPN IP, amelyikről tesztelsz és mondjuk folyamatosan pingeled a VM-et.

Megjegyzés: a masinának két lába van. Ha a .252 és .255 LAN fizikailag is következetesen mindenhol önálló lan, akkor nem bonyolítanám a dolgot vlan használatával.