[IPTables + Apache] Rewrite zonder apache

[Kippenijzer]

Ik kon zo geen helderdere korte title verzinnen helaas

Ik zit met het volgende probleem:
Ik heb een 3-tal servers waar verschillende services op draaien. De meeste services hebben een eigen IP en hostname, wat ook wenselijk is. Deze hostnames zijn verdeeld over de 3 systemen.
Bij een aantal services moet een webinterface komen voor zaken als status. Deze webinterface moet onder omstandigheden onder dezelfde hostname bereikbaar zijn. Gezien de verschillende services nogal CPU-hungry zijn, is het geen optie om apache op alle individuele systemen te draaien.
Eén van de systemen is zelf al een webserver, zodoende draait hier al apache op. Ik zou dus heel graag poort 80 verkeer op andere systemen door laten sturen naar dit bewuste systeem, zodat dit systeem alle websites host.
Normaliter zou je kunnen kiezen voor apache's mod-rewrite, maar da's hier geen optie, omdat je dan alsnog apache op de andere systemen moet draaien. Daarnaast kun je over het interne netwerk verkeer masqueraden, wat in zoverre niet wenselijk is dat de bewuste systemen dan alsnog "veel" extra moeten rekenen, aan de heen en terug masquerading zelf.
Zodoende wilde ik graag mbv IPTables dit verkeer doorsturen, echter werkt dit niet (in de zaken die ik getest heb) en verschillende zoektochten omtrent dit probleem hebben tot op heden ook niets opgeleverd, behalve dus Masquerading...
Ik zou graag op "een" manier het verkeer wat op server 2 en 3 binnenkomt op poort 80 herschrijven naar een poort op server 1, waar apache luistert, en daarvandaan de sites hosten.

Weet iemand of dit kan, en op welke manier, want het probleem waartegen ik op dit moment steeds aanloop is dat een request aan xxx.yyy.zzz.3:80 nu door xxx.yyy.zzz.1:80 geserveerrd worden, en blijkbaar begrijpt de opvragende webbrowser dit niet
Een lightweight alternatief voor apache's mod-rewrite zou eventueel ook nog kunnen, maar heeft in zoverre niet de voorkeur, gezien ook dan er weer extra programmaas op de andere systemen moeten gaan draaien.

[igmar]

2 oplossingen :

1) Een reverse proxy. Squid kan dat, Apache ook. Er zijn ook wel 'lichtere' alternatieven
2) Een transparante proxy. Dit vereist kernel patches, en behoorlijk wat IP kennis.

Ik zou voor #1 gaan, da's het meest simpele op te zetten.

[Gondor]

Als je static IP's hebt kan je NAT gebruiken ipv Masquerading. Dat eist minder cpu kracht omdat je niet iedere keer de IP's hoeft te berekenen.

[Kippenijzer]

Gondor schreef op 29 december 2003 @ 16:47:
Als je static IP's hebt kan je NAT gebruiken ipv Masquerading. Dat eist minder cpu kracht omdat je niet iedere keer de IP's hoeft te berekenen.

Dat is inderdaad hoe ik het probeerde, maar ik ben misschien wat onvolledig in mijn uitleg geweest zie ik nu Het gaat hier namelijk om 3 systemen die alle drie direct aan internet hangen. Ze hebben ook alle dire een eigen internet IP (meerdere zelfs ) en ik heb het verwijzen met -J DNAT al geprobeerd. Het probleem is dat ik alle poort 80 requests, op alle ip's die op server 2 en 3 gekoppeld zijn, wil forwarden naar het liefst 1 ip op de apache server, die dan fijn met namevirtualhosts moet gaan spelen. Dus het is geen mogelijkheid (nou jah, tuurlijk wel, maar dan moet ik naar heel veel IP's gaan verwijzen en weer terug, waardoor de IP-Tables tabellen nogal groot en dus trager worden) om heen en terug te -dnat en -snat-ten wat dat betreft

[Gondor]

Is een firewall oid tussen internet en die drie servers plaatsen en hem laten natten en mappen geen optie? En als je al een router-modem hebt hem dat laten doen?

Of als je meerdere IP's hebt voor elk server assign je toch gewoon de IP's van die andere servers toch aan de betreffende server. Of is dit niet mogelijk ivm andere services onder die IP's?

[Kippenijzer]

Ehm, de servers hangen rechtstreeks aan internet, in een colocatie ruimte. Het is geen optie er een systeem tussen te hangen, mede omdat de services die erop draaien (games ) ook erg happig zijn op iedere ms lagere ping

[igmar]

Kippenijzer schreef op 29 december 2003 @ 16:53:
[...]
Dat is inderdaad hoe ik het probeerde, maar ik ben misschien wat onvolledig in mijn uitleg geweest zie ik nu Het gaat hier namelijk om 3 systemen die alle drie direct aan internet hangen. Ze hebben ook alle dire een eigen internet IP (meerdere zelfs ) en ik heb het verwijzen met -J DNAT al geprobeerd. Het probleem is dat ik alle poort 80 requests, op alle ip's die op server 2 en 3 gekoppeld zijn, wil forwarden naar het liefst 1 ip op de apache server, die dan fijn met namevirtualhosts moet gaan spelen. Dus het is geen mogelijkheid (nou jah, tuurlijk wel, maar dan moet ik naar heel veel IP's gaan verwijzen en weer terug, waardoor de IP-Tables tabellen nogal groot en dus trager worden) om heen en terug te -dnat en -snat-ten wat dat betreft

Bovenstaande gaat ook niet weken indien je 1 NIC hebt : Er is dan geen sprake van IP forwarding, en je SNAT regels doen het niet (ervaring ).

Het meest simpele is echt de reverse proxy in dit geval, aangezien transparant proxy het ook waarschijnlijk niet zal doen.

[Kippenijzer]

igmar schreef op 29 december 2003 @ 17:46:
[...]


Bovenstaande gaat ook niet weken indien je 1 NIC hebt : Er is dan geen sprake van IP forwarding, en je SNAT regels doen het niet (ervaring ).

Het meest simpele is echt de reverse proxy in dit geval, aangezien transparant proxy het ook waarschijnlijk niet zal doen.

Het kan op zich wel, gezien als je met dnat iets heen vertaald, en het daarna terugroute naar de bak waarop het ge-dnat is, om het bij het uitgaan weer te snatten, zodat voor de ontvangende client hij toch van het "origineel opgevraagde" ip komt. Maar het is ondoebaar om dat voor ip's in de orde van grote van 500 stuks te doen (toekomstgericht denken zeg maar ;P)

Nou kan het zijn dat ik iets over het hoofd zie, maar in geval van de reverse proxy, moet ik toch alsnog op alle systemen de, in dit geval proxy, als extra programma gaan draaien?

[PolarWolf]

Kippenijzer schreef op 29 december 2003 @ 18:26:
[...]

Het kan op zich wel, gezien als je met dnat iets heen vertaald, en het daarna terugroute naar de bak waarop het ge-dnat is, om het bij het uitgaan weer te snatten, zodat voor de ontvangende client hij toch van het "origineel opgevraagde" ip komt. Maar het is ondoebaar om dat voor ip's in de orde van grote van 500 stuks te doen (toekomstgericht denken zeg maar ;P)

Dat redirecten lukt prima met DNAT/SNAT. Het is zelfs verbazend simpel. Maarruh, als het maar om een poort gaat die je altijd naar een andere server wilt laten redirecten, wat heeft het aantal IP addressen er dan mee te maken?

[Kippenijzer]

PolarWolf schreef op 29 december 2003 @ 21:46:
[...]


Dat redirecten lukt prima met DNAT/SNAT. Het is zelfs verbazend simpel. Maarruh, als het maar om een poort gaat die je altijd naar een andere server wilt laten redirecten, wat heeft het aantal IP addressen er dan mee te maken?

Het probleem is dat server 2 en drie allebei meerdere ip's hebben. Op dit moment gaat het dus maar om 3 servers, maar dit aantal zal in de toekomst toenemen.
Als van ieder systeem bijvoorbeeld 10 ip's op poort 80 doorgemapt worden voor websites, moet ik dus naar 10 adressen doormappen, en weer terugmappen. Doe ik dit niet, en map ik door naar één ip op de webserver, dan zal op het gros van de pc's die de pagina's op willen vragen via internet de sites niet werken, omdat hij iets opvraagt bij xxx.yyy.zzz.3, en een antwoord krijgt van een ander adres, omdat dit niet eenvoudig terug te mappen is alsof het van xxx.yyy.zzz.3 afkomstig was. Daarom het verhaal over de ip's. Voor enkele ip's is het een prima oplossing, maar het is ook hier niet te wenselijk om apache op tig extra adressen (en vooral poorten) te moeten laten luisteren, puur om de reverse mapping op orde te krijgen. Veel liever gebruik ik namevirtualhosts hiervoor, zodat ik alle sites qua httpd-configuratiefiles wat beter beheersbaar kan houden.

[Kippenijzer]

Zo ik nu na heb kunnen gaan moet het straks gaan lukken door gebruik te maken van een combinatie van dnat en snat, en dan over het interne netwerk de request te vertalen.

-dnat in de PREROUTING naar de webserver, en -snat in de POSTROUTING. Dan zal de webserver de request krijgen en verwerken, en de reply weer naar het opvragende IP sturen.
Nu nog hopen dat hij dit goed weet te tracken, gezien de request altijd vanuit de main IP van server 2 of 3 geforward wordt naar de webserver... Vanavond eens even wat testjes hiervoor doen.

[igmar]

Kippenijzer schreef op 29 december 2003 @ 18:26:
[...]

Het kan op zich wel, gezien als je met dnat iets heen vertaald

Nee, het kan niet : Er is geen sprake van forwarding, dus gelden de regels die je daarvoor opstelt niet.

Nou kan het zijn dat ik iets over het hoofd zie, maar in geval van de reverse proxy, moet ik toch alsnog op alle systemen de, in dit geval proxy, als extra programma gaan draaien?

Klopt, en daar kom je ook niet onderuit.

[PolarWolf]

Kippenijzer schreef op 30 december 2003 @ 16:11:
Zo ik nu na heb kunnen gaan moet het straks gaan lukken door gebruik te maken van een combinatie van dnat en snat, en dan over het interne netwerk de request te vertalen.

-dnat in de PREROUTING naar de webserver, en -snat in de POSTROUTING. Dan zal de webserver de request krijgen en verwerken, en de reply weer naar het opvragende IP sturen.
Nu nog hopen dat hij dit goed weet te tracken, gezien de request altijd vanuit de main IP van server 2 of 3 geforward wordt naar de webserver... Vanavond eens even wat testjes hiervoor doen.

http://www.linuxops.net/ipsec/ipsec-server-masquerade.html

Kijk daar maar es na. Heb ik al een tijdje geleden geschreven toen ik een vergelijkbaar probleem had.