Mivel a host és az összes guest egy alhálózatban van, megadhatod ugyanazokat a gateway és DNS beállításokat, amit a hostnak megadtál. Ha gagyi a router, akkor a gateway legyen a host IP címe, a hoston meg kell egy NAT forward.

Mivel a probléma felvetésének módja erős fejfájást okoz, előre is elnézést kérek a válasz miatt.

Nem kívánok a Cisco nevében beszélni, de közel lehetetlen amit szeretnél (mivel megoldásokat szállítanak ők is és nem vágyakat elégítenek ki). Ugyanis a kívánt layer4 (vagy layer7 – szemlélet és implementáció kérdése) routing nem nagyon valósítható meg, ha a
– „A meglévő két szervert már nem nagyon piszkálnám…”
– „Az egyik router már proxys”
– „a kliensektől jövő hívott oldal címe! és/vagy a portok alapján irányítsam”
feltételek bármelyikét meg kívánod tartani. (A második azért problémás, mert a proxy nem egy szoftver neve, hanem egy szolgáltatás. Ráadásul két proxy szoftver ritkán tudja ugyanazt ugyanúgy.)

Az _amit_ szeretnél megoldható, de _ahogy_ szeretnéd hogy megvalósuljon az már agyament dolog. Ha a két „router” egy-egy PC, akkor három proxy segítségével megoldható a következő módon:
– a két router-en levő proxy csak a harmadik proxytól fogad kapcsolatot, ajánlott proxy: squid (a cache hasznos lehet, de csak opció),
– a harmadik proxy egy HA-Proxy, ahol meg van adva a következő három (és a többi) konfig opció:
balance roundrobin
server s1
server s2

– a klienseknél a default gateway (windows: átjáró) a harmadik proxy IP címe
– a harmadik proxy mehet akár az egyik router-en is, ha a squid nem az alapértelmezett portokat portot használja (pl. 8080 és 8443)
– külön-külön kell megadni a 80-as és a 443-as portokra vonatkozó szabályokat.

Így a hálózati késleltetés (latency) megnő és csak a HTTP forgalom kerül továbbításra, de a kliensek számára transzparens, és közel optimális a sávszélesség kihasználtság több aktív kliens esetén (az URL és port mágiához hasonlítva).

Hogy miért kell három proxy? Mert a HA-Proxy nem ismer egyetlen egy gateway protokollt sem, csak IP-re továbbít. Ha ilyesmi kell, akkor az már hardveresen megy és nem két forint. Például BGP/CEF/RIP alapú megolgások. Régen a Linux Virtual Server (KTCPVS) is tudott valami hasonlót,.de már nem fejlesztik.

http://www.squid-cache.org/
http://haproxy.1wt.eu/
http://kb.linuxvirtualserver.org/wiki/KTCPVS

A vhost alapú forgalomirányítás user-space layer-4, a többi (session, file típus kezelés, GET/POST manipuláció, stb.) már layer-7. De minderre magadtól is rájöhettél volna, ha utánanézel mi is a korábban emlegetett OSI modell.

Lényegében igen, így van. Viszont ez nem teljes értékű port forward, mivel a szelekció nem TCP/IP, hanem HTTP (layer 4) szinten van. Azaz nem bitazons, hanem tartalomazonos módon továbbít (akár extra mezőket is be lehet szúrni). Amit szeretnél elérni, azt kizárólag olyan módszerrel lehet kivitelezni, ami értelmezni tudja a HTTP fejlécet. Viszont az Apache nem egy „buta port forward” dolgot művel, hanem egy fejléc szűrés után képes szinte bármire. Neked egy egyszerű domain szintű átirányítás kell (értelmezve amit eddig írtál), viszont lehetőség van alkönyvtári szintű vagy kiterjesztés szerinti átirányításra is. Sőt, terhelésmegosztás (server level load balancing) is megoldható. Mivel proxy-ként csak a HTTP kéréseket szelektálja és a válaszokat továbbítja visszirányban, teljesen lényegtelen hogy milyen webszerver szolgálja ki a kéréseket. Egy lényeges hátránya van, nagyobb a teljesítmény igénye mint a kernel szintű port forwardnak, mivel a HTTP fejléc szöveges (a TCP bináris és fix méretű) és az összes aktív kapcsolat a tűzfal/proxy-n is nyitott lesz. Viszont ha egy nagyobb gép megfelelően nagy memóriával, akkor akár egy cache-t is lehetne rá tenni a képeknek és az egyéb statikus tartalomnak. Szóval egy 386-os szintű gép kevés lesz (a kernel szintű TCP port forward esetén azért elvisz egy 10MBit/s forgalmat), de egy lényegesen gyorsabb gépet is hasznossá lehet tenni a gyorstárazás segítségével. Lehet esetleg célszoftvert is feltenni az Apache/lighthttpd helyett, de például. a HAProxy esetén ágyúval lövöldöznél verébre.