Hallo Liste,
ich hab wahrscheinlich eine Denkblockade, was die korrekte Formulierung von Suchbegriffen angeht:
Es geht darum ein Linuxmachinchen an einen DSL-Anschluss zu stellen und "dahinter" gibt es diverse Windowswebserver. In der ersten Ausbaustufe soll das DNS URLS wie a.domain.tld und b.domain.tld auf die DSL-IP legen, auf der Linuxbox lauscht dann auf Port 80 $daemon, der dafür sorgt, dass REQUESTS an a.domain.tld unverändert an den einen Windowsserver gehen und die an b.domain.tld an den anderen. In einer zweiten Stufe könnte HTTPS dazukommen, es würde aber genügen, wenn nur bis Linux verschlüsselt ist, intern geht auch unverschlüsselter traffic.
Mir drängt sich da "Reverse Proxy" auf, aber alles was ich da im Web an Erklärungen und Anleitungen gerade finde arbeitet mit Umschreibungen der URL - das will ich nicht.
Ann mir bitte jemand eine ganz andere Richtung geben oder wenn mein Ansatz richtig war auf eine Anleitung verweisen, die eine URL unmanipuliert weiterroutet? Danke.
Mit freundlichen Grüßen / Kind regards Ronny Seffner
Hallo Ronny,
schau dir mal das libapache2-mod-proxy-html an.
Meine Config ist dafür ist angehängt und läuft so wie sie ist.
Die Ausbaustufe zwei bekommst du mit der -ssl Datei, ich habe jeweils die light.ak-online.be und light.ak-online.be-ssl Dateien in /etc/apache2/sites-available/ liegen und nach site-enabled gesymlinkt.
Für deine Stufe eins musst du nur die drei Files nach available kopieren und die $hostname file nach available linken.
Gruß, Andre
On Thu, Nov 10, 2011 at 05:46:16PM +0100, Ronny Seffner wrote:
Hallo Liste,
ich hab wahrscheinlich eine Denkblockade, was die korrekte Formulierung von Suchbegriffen angeht:
Es geht darum ein Linuxmachinchen an einen DSL-Anschluss zu stellen und "dahinter" gibt es diverse Windowswebserver. In der ersten Ausbaustufe soll das DNS URLS wie a.domain.tld und b.domain.tld auf die DSL-IP legen, auf der Linuxbox lauscht dann auf Port 80 $daemon, der dafür sorgt, dass REQUESTS an a.domain.tld unverändert an den einen Windowsserver gehen und die an b.domain.tld an den anderen. In einer zweiten Stufe könnte HTTPS dazukommen, es würde aber genügen, wenn nur bis Linux verschlüsselt ist, intern geht auch unverschlüsselter traffic.
Mir drängt sich da "Reverse Proxy" auf, aber alles was ich da im Web an Erklärungen und Anleitungen gerade finde arbeitet mit Umschreibungen der URL
- das will ich nicht.
Ann mir bitte jemand eine ganz andere Richtung geben oder wenn mein Ansatz richtig war auf eine Anleitung verweisen, die eine URL unmanipuliert weiterroutet? Danke.
Danke Andre,
So habe ich mir das gedacht, aber nirgends ein Beispiel gesehen. Deine Config setzt aber voraus, dass:
a) der DNS im WAN light.ak-online.be mit dem A record auf die IP des Apachen im Proxy mode auflöst und b) der DNS (oder nur die /etc/hosts) des Apachen für den A record zu light.ak-online.be eben "nur" eine lokale IP (die des eigenlichen Webservers) liefert
Habe ich das richtig verstanden?
Mit freundlichen Grüßen / Kind regards Ronny Seffner
Hallo Ronny,
On Thu, Nov 10, 2011 at 06:11:55PM +0100, Ronny Seffner wrote:
Danke Andre,
So habe ich mir das gedacht, aber nirgends ein Beispiel gesehen. Deine Config setzt aber voraus, dass:
a) der DNS im WAN light.ak-online.be mit dem A record auf die IP des Apachen im Proxy mode auflöst und b) der DNS (oder nur die /etc/hosts) des Apachen für den A record zu light.ak-online.be eben "nur" eine lokale IP (die des eigenlichen Webservers) liefert
Habe ich das richtig verstanden?
Ja, das hast du. Mein Setup an der Stelle hat den Trick, dass ich intern wie extern dieselbe Domain benutze, aber ein split-DNS fahre. Also lösen alle lokal erreichbaren Hosts mit einer internen IP auf, alle Hosts extern bekommen nur meine dynamische IP zurück (bzw. sind CNAMES auf vpn.ak-online.be).
Du kannst aber stattdessen auch jede beliebige IP/Hostnamen in der Apache-Config erwähnen. Das der Name intern wie extern bei mir light.ak-online.be ist, ist da eher der seltene Fall. Bei mir habe ich eben den Vorteil, dass ich auf allen Maschinen ein name-based virtualHosting im Apache fahren kann, und ich auch die Zertifikate dafür nur einmal von der CACert.org ausstellen lassen muss, statt mit jedem indivituellen Server für die gleiche Domain ein anderes Zertifikat zu verwenden.
Du kannst z.B. auch deinen Apache dazu bringen, dass er zu ressource.internal zugreift, auch wenn der Name ressource.globale.domain ist.
Gruß, Andre
Hallo Andre und Heiko,
das Thema mir einen Loadbalancer statt einen Reverseproxy anzuschauen (pound) hat auch meinen Schirm erreicht. Dennoch hat mit Andrés "Trick" mit dem lokal manipulierten DNS bereits genügt. Weil im Background ein Sharepoint läuft darf da eben absolut nichts an der URL oder dem Port manipuliert werden und da reicht mod_proxy mit einer speziellen hosts vollkommen aus.
Danke, für Eure Mühen.
Mit freundlichen Grüßen / Kind regards Ronny Seffner
Ronny Seffner ronny@seffner.de (Thu Nov 10 17:46:16 2011):
Hallo Liste,
ich hab wahrscheinlich eine Denkblockade, was die korrekte Formulierung von Suchbegriffen angeht:
Es geht darum ein Linuxmachinchen an einen DSL-Anschluss zu stellen und "dahinter" gibt es diverse Windowswebserver. In der ersten Ausbaustufe soll das DNS URLS wie a.domain.tld und b.domain.tld auf die DSL-IP legen, auf der Linuxbox lauscht dann auf Port 80 $daemon, der dafür sorgt, dass REQUESTS an a.domain.tld unverändert an den einen Windowsserver gehen und die an b.domain.tld an den anderen. In einer zweiten Stufe könnte HTTPS dazukommen, es würde aber genügen, wenn nur bis Linux verschlüsselt ist, intern geht auch unverschlüsselter traffic.
versuche mal mit
$daemon = "pound";
„Unverändert weiterleiten“ heißt aber trotztem, daß der Proxy dann die Requests auslöst, d.h., für die Backends kommen die Anfragen vom Proxy, was dumm ist, wenn dort irgendetwas sich auf Quell-IPs verläßt. Logging wäre nicht das Problem, Pound kann Logs so schreiben, wie es ein Apache auch tun würde und die lassen sich dann prima webalizen oder was auch immer.
An den Requests wird nichts umgeschrieben, notfalls könnte er bei Location-Headern der Response eingreifen, falls die Backends auf die Idee kommen, daß sie sich dort selbst eintragen müssten.
HTTPS kann er terminieren oder als MITM arbeiten, falls die Backends auf HTTPS bestehen.
Sicher gehen auch diverse Apache-Module und auch der Squid läßt sich für sowas verwenden.
lug-dd@mailman.schlittermann.de
-
Andre Klärner -
Heiko Schlittermann -
Ronny Seffner