Anfragen komplett auf anderen Server umleiten mit Proxy

[Speedysurf]

Ich möchte nach einem Serverwechsel alle Anfragen die auf den alten eintreffen (http,https, Mail) auf den neuen umleiten.
Dazu habe ich folgendes in der VirtualHost Datei eingetragen:

ProxyRequests Off
ProxyPass / http://IP-Neuer-Server/ 
ProxyPreserveHost On

Die Webseiten werden auch sauber weitergeleitet. Was allerdings nicht funktioniert sind die https Aufrufe um z.B. in das i-mscp ControlPanel zu kommen. Ich habe auch in der ssl conf o.g. Proxyeintrag vorgenommen, aber es funktioniert nicht. Mail konnte ich auch nicht testen, da es momentan nur 2 Testmaschinen sind.
Wie kann ich also komplett alle Anfragen auf den neuen Server umleiten.

 

[Whistler]

Wie möchtest Du die Anfragen weiterleiten?
Auf dem alten (mit altem Zertifikat) entschlüsseln und dann weiterreichen? Dann brauchst Du "SSLProxyEngine on".
Gekapselt an den neuen weiterleiten (neues Zertifikat)? Dann brauchst Di mod_proxy_connect.

 

[Speedysurf]

Der Server wird 1:1 übernommen, so dass die Zertifikate identisch bleiben. Es sollen eben alle Anfragen auf dem neuen landen. Was ist da die bessere Variante?

 

[wstuermer]

Du suchst nach rinetd - Da du ja alles umleiten willst.

 

[d4f]

rinetd stellt das Problem dass auf dem Ziel-Server alle Verbindungen den Anschein haben vom alten Server zu stammen, die Logs sind also absolut unbrauchbar und es kann zu Problemen mit Sessions führen.
Zumal bei Emails kann rinetd zu weiteren Problemen führen da DNSBL's als wirksamer Spamschutz aussen vor bleibt.

Der alte Server sollte in diesem Fall die SSL-Terminierung übernehmen und die entschlüsselte Verbindung an den neuen weiterreichen.
Falls du dem Netz zwischen beiden Servern nicht ausreichend vertraust, eine VPN-Verbindung zwischen beiden Machinen aufbauen.
Auf dem Zielserver sollte übrigens noch Apache's mod_rpaf aktiv sein um die Absender-IP's zu korrigieren.

E-Mails werden nicht vom HTTP Proxy übernomen, aber generell stellt es kein Problem dar wenn 2-3 Stunden falsche DNS-Einträge da stehen da das Protokoll ein Zwischenspeicher beim Absender vorsieht, typischerweise in der Praxis 1-3 Tage. Bei entsprechenden TTL-Werten ist die effektive Downtime unter einer Stunde.

 

[s24!]

E-Mails werden nicht vom HTTP Proxy übernomen, aber generell stellt es kein Problem dar wenn 2-3 Stunden falsche DNS-Einträge da stehen da das Protokoll ein Zwischenspeicher beim Absender vorsieht, typischerweise in der Praxis 1-3 Tage. Bei entsprechenden TTL-Werten ist die effektive Downtime unter einer Stunde.

Sehe ich genauso. E-Mails gehen ja nicht verloren; du könntest aber auch schon vorab den neuen Server als MX setzen. Den Aufwand der Weiterleitung würde ich mir gar nicht machen wollen... Meiner Erfahrung nach halten sich > 95% aller Clients an eine TTL von 300 Sekunden, und ein 300-Sekunden-Lag bei der Mailzustellung sollte vertretbar sein.
Falls du doch weiterleiten willst: NGINX kann auch als Mail-Proxy arbeiten.

 

[infinitnet]

Warum nicht einfach per NAT oder GRE alles tunneln? Alles Andere ist doch völliger Quatsch, solange auf dem alten Server nicht statische Inhalten zwischengespeichert oder sonst manipuliert werden sollen. Wundert mich, dass das noch nicht vorgeschlagen wurde, da es genau das ist, wonach der OP, soweit ich das verstehe, sucht. Lösung per iptables NAT:

alte_ip = die IP des Servers der weiterleiten soll
neue_ip = die IP des Servers auf den weitergeleitet werden soll

Auf dem alten Server:

# sysctl -w net.ipv4.ip_forward=1
# iptables -t nat -A PREROUTING  -p tcp -d $alte_ip -j DNAT --to-destination $neue_ip
# iptables -t nat -A POSTROUTING -p tcp --dst $neue_ip -j SNAT --to-source $alte_ip
# iptables -A FORWARD -p tcp -d $neue_ip -j ACCEPT

Selbiges kann man dann bei Bedarf auch noch mit "-p udp" machen, um UDP weiterzuleiten.

 

[d4f]

Warum nicht einfach per NAT oder GRE alles tunneln? Alles Andere ist doch völliger Quatsch, solange auf dem alten Server nicht statische Inhalten zwischengespeichert oder sonst manipuliert werden sollen

Den Grund habe ich 2 Posts höher beschrieben =)
Ich halte es für gefährlich, solche Methoden vor zu schlagen ohne auf die entsprechenden Risiken hin zu weisen.

 

[infinitnet]

Nunja, auf die Risiken hast du ja schon hingewiesen.
Da der OP anscheinend nur User, welche noch nicht über den Serverwechsel informiert wurden, auf den neuen leiten möchte, sollte es sich zumindest theoretisch nur um einen Bruchteil handeln, was die Risiken dann auch nicht mehr sooo dramatisch macht.