Dotaz: OpenVZ a dvě síťová rozhraní

[Eregon]

Zdravím všechny, narazil jsem na zapeklitý problém při nasazení OpenVZ, kdy se síťový provoz z VPS směřuje přes nesprávné rozhraní.

Výchozí situace: Mám dva fyzické servery. Jeden z nich (říkejme mu Servant) poskytuje určité služby, které jsou využívány z dalších serverů. Druhý (říkejme mu Host) je hostitelským serverem pro provoz virtuálních serverů založených na OpenVZ.

Oba tyto stroje mají dvě síťové karty, přičemž přes eth0 se oba připojují do vnější sítě (1.2.3.0/24), zatímco přes eth1 se připojují do vnitřní sítě (192.168.1.0/24). Tzn. pro přesnější představu: mám několik serverů, každý z nich je ve dvou sítích, které se liší tím, že jedna je pouze pro komunikaci mezi nimi navzájem, druhá je určena pro komunikaci s vnějším světem.

Na serveru Host dále běží nějaké VPS, pro účely tohoto dotazu je jeden, kterému budu říkat prostě Vps. Až na to, že nemá své vlastní železo, je to server jako všechny ostatní v síti, takže i tento server je připojen do vnější i vnitřní sítě a využívá služby ze serveru Servant.

Tzn. v souhrnu síťová konfigurace vypadá nějak takhle:

Servant   192.168.1.1   1.2.3.1
Host      192.168.1.2   1.2.3.2
Vps       192.168.1.3   1.2.3.3

A teď ten slavný problém. Když se z Vps připojím na Servant skrze vnitřní síť (tzn. příkazem ssh user@192.168.1.1), připojení sice proběhne, ale na stroji Servant se pak příkazem who dozvídám, že nejsem připojený z adresy 192.168.1.3, ale z 1.2.3.3. Tzn. pakety určené pro vnitřní síť putují po té vnější, což je problém z mnoha důvodů.

Podle mého dosavadního zkoumání problém může souviset s tím, že OpenVZ přiřazuje jednotlivým VPS adresy s netmaskou /32, takže se na cestě mezi venet0 na Host a fyzickým rozhraním nějak blbě upraví a nasměrují se špatně.

Přiznám se, že mi ne zcela dochází, jak to, že se na vnější síti vůbec podaří najít správný server, takže ani moc dobře nevím, kam šáhnout a co změnit, aby se pakey poslušně odebíraly ven přes eth1.

Určitým nápadem je znásilnit OpenVZ, aby nastavovalo masku /24, všude se ale doporučuje tuhle věc nedělat (bohužel bez vysvětlení). Další možností by mohlo být nějaké veselé nastavení iptables, které by vynutilo směrování odpovídajících paketů na eth1.

Nejdřív jsem se ale chtěl zeptat, jestli někdo neřešil něco podobného, abych nevynalézal kolo se spoustou vedlejších efektů. P5edem dík za všechny odpovědi.

Odpovědi

[Karel Tuma]

takze jenom kratce - vnet je na vz nejvetsi zlo. daleko jednodussi je vzdy pouzit bridge, sit se pak chova tak jak jeden ceka, tj:

vzctl set 20 --netif_add eth0,00:DE:AD:BA:BE:00,vzeth0,00:DE:AD:BA:BE:01 --save

vytvori eth0 v kontextu 20, druhy konec interfacu se jmenuje vzeth0 (prida se do bridge
vmbr0 ktery jiz musi existovat)

a v kontejneru nastavit spravne /etc/network/interfaces. dale je treba vytvorit
/etc/vz/vznet.conf a v nem mit EXTERNAL_SCRIPT="/usr/local/sbin/vznetaddbr

konteiner se pote po startu prida do bridge 'vmbr0' (ten si musis udelat, nabridgovat kam potrebujes)

vice navod na http://wiki.openvz.org/Virtual_Ethernet_device

mimochodem v tvem pripade by nebylo od veci mozna v ct0 pouzivat tagovane vlan, neni treba pak mit 2 sitovky. tagovane
vlany jsou v kazdem ohledu sitove zarizeni.

[Eregon]

Díky za tip, ale jak se na to dívám, tak tím bridgem zaberu celé ethX pro jeden virtuál, nebo se pletu?

Asi jsem to předtím špatně vysvětlil, ale podobných virtuálů na tom jednom fyzickém stroji je mnohem víc (snažil jsem se omezit popis jen na významné části situace), takže si nemůžu dovolit každému dát jednu fyzickou síťovku.

Každopádně to ještě prozkoumám detailněji.