2
Dynamisches NAT-routing
Hallo,
es geht um folgendes:
Wir bauen in unserer Firma ein neues Netzwerk mit 2 ISP's auf.
1x 10mbit/s symethrisch und 1x 100mbit/s symethrisch.
Auf der 100 Mbit/s Leitung warten 2 Xeon-Server (2 verschiedene WAN IP's) mit Pfsense auf einkommenden Traffic.
Diese laufen redundant als Failover.
Auf der 10 Mbit/s Leitung nur ein System, dass nur als Backup dienen soll wenn die dicke Leitung ausfällt.
Ein dynamischer DNS-Server ermöglicht das Failover im Falle eines Ausfalls Gatewayseitig oder ISPseitig.
Mein großes Problem findet allerdings im LAN statt, nicht im WAN.
Wir hosten 2 IBM Dubi server mit jeweils 24TB gespiegelt über 3 Etagen hinweg. (Glassfaser SX-LC multimode + Gigabit)
Auf den Xeonservern läuft ja wie gesagt Pfsense.
Mein Problem ist, dass ich Port 80 zu einem der IBM Dubi Server forwarden will, nur was passiert wenn der Server ausfällt und der andere redundante IBM Dubi als Apache Server auf port 80 dient?? Pfsense bzw. generell ein Gateway stellt ja weiterhin auf die LAN-IP des eingetragenen (und in diesem Fall ausgefallenen) Systems durch.
Meine Idee ist eventuell von beiden Servern einer LAN-Karte die selbe IP zu geben und die eine direkt zu aktivieren, wenn sie merkt das der andere ausfällt...
Habt ihr Ideen?
Achso, eventuell hilft es weiter das wir 2x 24 Gigabit Layer2 Managed switches haben die auch virtual ip unterstützen würden.
Danke und lieben Gruß,
John
es geht um folgendes:
Wir bauen in unserer Firma ein neues Netzwerk mit 2 ISP's auf.
1x 10mbit/s symethrisch und 1x 100mbit/s symethrisch.
Auf der 100 Mbit/s Leitung warten 2 Xeon-Server (2 verschiedene WAN IP's) mit Pfsense auf einkommenden Traffic.
Diese laufen redundant als Failover.
Auf der 10 Mbit/s Leitung nur ein System, dass nur als Backup dienen soll wenn die dicke Leitung ausfällt.
Ein dynamischer DNS-Server ermöglicht das Failover im Falle eines Ausfalls Gatewayseitig oder ISPseitig.
Mein großes Problem findet allerdings im LAN statt, nicht im WAN.
Wir hosten 2 IBM Dubi server mit jeweils 24TB gespiegelt über 3 Etagen hinweg. (Glassfaser SX-LC multimode + Gigabit)
Auf den Xeonservern läuft ja wie gesagt Pfsense.
Mein Problem ist, dass ich Port 80 zu einem der IBM Dubi Server forwarden will, nur was passiert wenn der Server ausfällt und der andere redundante IBM Dubi als Apache Server auf port 80 dient?? Pfsense bzw. generell ein Gateway stellt ja weiterhin auf die LAN-IP des eingetragenen (und in diesem Fall ausgefallenen) Systems durch.
Meine Idee ist eventuell von beiden Servern einer LAN-Karte die selbe IP zu geben und die eine direkt zu aktivieren, wenn sie merkt das der andere ausfällt...
Habt ihr Ideen?
Achso, eventuell hilft es weiter das wir 2x 24 Gigabit Layer2 Managed switches haben die auch virtual ip unterstützen würden.
Danke und lieben Gruß,
John
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 142330
Url: https://administrator.de/contentid/142330
Printed on: April 26, 2024 at 05:04 o'clock
2 Comments
Latest comment
Ja, das geht nur so ! Der Port Forwarding Eintrag auf der PFsense zeigt ja auf eine feste IP und wenn die nicht mehr da ist ist "Schicht im Schacht" !
Du kannst das also nur mit einem Clustering der IP Adressen zwischen beiden Maschinen lösen, das die eine IP Adresse sharen wie z.B. das beim VRRP Protokoll der Fall ist.
Damit übernehmen die Web Server dann im Failover Falle immer diese IP und gut ist.
Die andere Möglichkeit ist Policy Based Routing sprich PBR zu verwenden mit einem redundanten next Hop. Das wiederum aber supportet die Pfsense m.W. nicht.
Leider bist du nur sehr oberflächlich was deine Beschreibung der "managed Switches" anbetrifft
Was soll "virtual IP" sein ?? VRRP ??
Können die Layer 3, also Routing ??
Wenn ja, supporten sie PBR ??
Wenn ja, dann kannst du das sehr elegant mit PBR lösen ansonsten bleibt dann nur die Clusterlösung.
Oder ein anderer "Quick and Dirty Workaround"... du machst auf der 10 Mbit Leitung auch ein Port Forwarding auf den anderen Server. Das Problem da ist dann aber das remote Clients nur sehen das der erste Server weg ist (Timeout). Sie müssen dann selbsständig auf die Idee kommen die andere (10 Mbit) WAN IP für den Zugang zum 2ten Server zu nehmen. Eine Automatismus mit Bordmitteln gibt es dann da nicht.
Übrigens: NAT und Routing sind 2 unterschiedliche Baustellen ! "NAT Routing" gibt es nicht !!
Du kannst das also nur mit einem Clustering der IP Adressen zwischen beiden Maschinen lösen, das die eine IP Adresse sharen wie z.B. das beim VRRP Protokoll der Fall ist.
Damit übernehmen die Web Server dann im Failover Falle immer diese IP und gut ist.
Die andere Möglichkeit ist Policy Based Routing sprich PBR zu verwenden mit einem redundanten next Hop. Das wiederum aber supportet die Pfsense m.W. nicht.
Leider bist du nur sehr oberflächlich was deine Beschreibung der "managed Switches" anbetrifft
Was soll "virtual IP" sein ?? VRRP ??
Können die Layer 3, also Routing ??
Wenn ja, supporten sie PBR ??
Wenn ja, dann kannst du das sehr elegant mit PBR lösen ansonsten bleibt dann nur die Clusterlösung.
Oder ein anderer "Quick and Dirty Workaround"... du machst auf der 10 Mbit Leitung auch ein Port Forwarding auf den anderen Server. Das Problem da ist dann aber das remote Clients nur sehen das der erste Server weg ist (Timeout). Sie müssen dann selbsständig auf die Idee kommen die andere (10 Mbit) WAN IP für den Zugang zum 2ten Server zu nehmen. Eine Automatismus mit Bordmitteln gibt es dann da nicht.
Übrigens: NAT und Routing sind 2 unterschiedliche Baustellen ! "NAT Routing" gibt es nicht !!
Ein dynamischer DNS-Server ermöglicht das Failover im Falle eines Ausfalls Gatewayseitig oder ISPseitig.
Das würde bedeuten, dass ihr die TTL für die DNS-Einträge auf < 5 Minuten gestellt habt (denn sonst macht das mit DNS ja keinen Sinn) und das ist bei echten Servern schon Frevel.
Die eigentliche Frage ist: Welche Protokolle müssen ins Internet freigegeben werden?
Wenn es nur HTTP ist macht es oft eher sind einen Reverse-Proxy ala pond oder Varnish zu benutzen, die Failover-Szenarien beherrschen.
