136845
02.08.2018
4305
8
0
Redundante Internetanbindung und öffentliche IP
Hallo,
wir haben vor eine Backup Leitung (anderer Provider) zu nutzen. Hintergrund ist das die Hauptleitung (Glasfaser) bereits zweimal ausgefallen ist. Nun haben wir natürlich das Thema, dass wir verschiedene Dienste öffentlich anbieten (RemoteApps, Standortvernetzung, Fileserver,...) und die auch bei Ausfall der Hauptleitung verfügbar sein sollen.
Bislang gäbe es zwei Varianten:
1. Mittels FQDN (Bsp. xyz.muster.de, zzz.muster.de,...) arbeiten und je FQDN die beiden IP-Adressen (eine IP aus dem Primärleitung, eine IP aus der Sekundärleitung) über die der Dienst verfügbar wäre hinterlegen. Die Idee entstammt von einem Dienstleister, der uns betreut.
2. EInen VPN-Tunnel zwischen lokaler Firewall zu einer Firewall im Rechenzentrum aufbauen und die öffentlichen Dienste über den Tunnel routen. Bei Ausfall der Hauptleitung und VPN-Tunnel würde der andere Tunnel die Dienste übernehmen.
Generell frage ich mich ob die 1. Variante überhaupt so realisierbar wäre? Insbesondere in Hinblick dessen, dass man dort - soweit mir bekannt - nicht steuern könnte welche IP und somit Leitung genommen werden soll.
Was sagt Ihr dazu?
Gruß
wir haben vor eine Backup Leitung (anderer Provider) zu nutzen. Hintergrund ist das die Hauptleitung (Glasfaser) bereits zweimal ausgefallen ist. Nun haben wir natürlich das Thema, dass wir verschiedene Dienste öffentlich anbieten (RemoteApps, Standortvernetzung, Fileserver,...) und die auch bei Ausfall der Hauptleitung verfügbar sein sollen.
Bislang gäbe es zwei Varianten:
1. Mittels FQDN (Bsp. xyz.muster.de, zzz.muster.de,...) arbeiten und je FQDN die beiden IP-Adressen (eine IP aus dem Primärleitung, eine IP aus der Sekundärleitung) über die der Dienst verfügbar wäre hinterlegen. Die Idee entstammt von einem Dienstleister, der uns betreut.
2. EInen VPN-Tunnel zwischen lokaler Firewall zu einer Firewall im Rechenzentrum aufbauen und die öffentlichen Dienste über den Tunnel routen. Bei Ausfall der Hauptleitung und VPN-Tunnel würde der andere Tunnel die Dienste übernehmen.
Generell frage ich mich ob die 1. Variante überhaupt so realisierbar wäre? Insbesondere in Hinblick dessen, dass man dort - soweit mir bekannt - nicht steuern könnte welche IP und somit Leitung genommen werden soll.
Was sagt Ihr dazu?
Gruß
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 382112
Url: https://administrator.de/forum/redundante-internetanbindung-und-oeffentliche-ip-382112.html
Ausgedruckt am: 14.04.2025 um 09:04 Uhr
8 Kommentare
Neuester Kommentar
Moin,
Ob man das steuern kann oder nicht, hängt vom DNS-Server ab. Bei BIND kann man einstellen, in welcher Reihenfolge die IPs ausgeliefert werden (zyklisch, zufällig oder fest). Die Frage ist allerdings, ob die Clientsoftware damit zurechtkommt. Die muss in der Lage sein, wenn die erste IP nicht geht, auf die zweite zu switchen, ohne dass händisch eingegriffen werden muss. Das musst Du halt testen (lassen).
hth
Erik
Zitat von @136845:
Generell frage ich mich ob die 1. Variante überhaupt so realisierbar wäre? Insbesondere in Hinblick dessen, dass man dort - soweit mir bekannt - nicht steuern könnte welche IP und somit Leitung genommen werden soll.
Ob man das steuern kann oder nicht, hängt vom DNS-Server ab. Bei BIND kann man einstellen, in welcher Reihenfolge die IPs ausgeliefert werden (zyklisch, zufällig oder fest). Die Frage ist allerdings, ob die Clientsoftware damit zurechtkommt. Die muss in der Lage sein, wenn die erste IP nicht geht, auf die zweite zu switchen, ohne dass händisch eingegriffen werden muss. Das musst Du halt testen (lassen).
hth
Erik
Hallo,
wenn schon die Variante 2 in Erwägung gezogen wurde, so macht es doch Sinn, die betroffenen Dienste gleich in ein RZ zu verlagern. Damit ist das Thema Verfügbarkeit erledigt (soweit das RZ mit SLAs arbeitet).
vG
LS
wenn schon die Variante 2 in Erwägung gezogen wurde, so macht es doch Sinn, die betroffenen Dienste gleich in ein RZ zu verlagern. Damit ist das Thema Verfügbarkeit erledigt (soweit das RZ mit SLAs arbeitet).
vG
LS
...und das RZ natürlich auch eine redundante Anbindung hat. 
Ansonsten wäre es auch wieder sinnfrei.
Ansonsten wäre es auch wieder sinnfrei.
@erikro
@136845
@laster
Gruß,
Dani
Ob man das steuern kann oder nicht, hängt vom DNS-Server ab. Bei BIND kann man einstellen, in welcher Reihenfolge die IPs ausgeliefert werden (zyklisch, zufällig oder fest).
Schön und gut... aber wie trickst du den DNS Cache Server aus? TTL des DNS-Eintrags auf 5 setzen oder wie hast du das gedacht?@136845
Hintergrund ist das die Hauptleitung (Glasfaser) bereits zweimal ausgefallen ist.
Das ist relativ. Das hängt a) vom Provider ab b) vom Produkt c) von den SLAs.1. Mittels FQDN (Bsp. xyz.muster.de, zzz.muster.de,...) arbeiten und je FQDN die beiden IP-Adressen (eine IP aus dem Primärleitung, eine IP aus der Sekundärleitung) über die der Dienst verfügbar wäre hinterlegen. Die Idee entstammt von einem Dienstleister, der uns betreut.
Das geht auf Dauer nicht gut. Wann weiß ein Benutzer, wenn xyz.muster.de nicht erreichbar ist, ob es an seinem ISP bzw. WLAN Hotspot oder an euch liegt? Das führt aus Erfahrung heraus nur zur Verwirrung.2. EInen VPN-Tunnel zwischen lokaler Firewall zu einer Firewall im Rechenzentrum aufbauen und die öffentlichen Dienste über den Tunnel routen. Bei Ausfall der Hauptleitung und VPN-Tunnel würde der andere Tunnel die Dienste übernehmen.
Dann würde ich die Services gleich ins RZ stellen und immer über einen VPN-Tunnel die Daten bereitstellen. Somit kannst du dir einiges an Komplexität, Nerven und Zeit sparen. Fällt Leitung a) wird der VPN-Tunnel erneut aufgebaut. Alternativ wird über beide ISP jeweils aktiv ein VPN-Tunnel aufgebaut und beim Ausfall ändert sich nur das Routing. Ist je nach Szenario ein Ticken schneller.@laster
wenn schon die Variante 2 in Erwägung gezogen wurde, so macht es doch Sinn, die betroffenen Dienste gleich in ein RZ zu verlagern. Damit ist das Thema Verfügbarkeit erledigt (soweit das RZ mit SLAs arbeitet).
Es wäre eine Art ReverseProxy/Edge Router. Den könnte man auch noch redudant auslegen, so dass bei Wartungsarbeiten oder Störungen der Betrieb aufrecht bleibt.Gruß,
Dani
Moin,
Gute Frage. Ich habe ja auch nur gesagt, dass man das bedingt steuern kann, welche IP bevorzugt verteilt wird. Praktikabel ist das nicht wirklich, zumal es Software gibt, die stur den ersten Eintrag nimmt und den zweiten ignoriert.
Liebe Grüße
Erik
Zitat von @Dani:
@erikro
@erikro
Ob man das steuern kann oder nicht, hängt vom DNS-Server ab. Bei BIND kann man einstellen, in welcher Reihenfolge die IPs ausgeliefert werden (zyklisch, zufällig oder fest).
Schön und gut... aber wie trickst du den DNS Cache Server aus? TTL des DNS-Eintrags auf 5 setzen oder wie hast du das gedacht?Gute Frage.
Ich habe ja auch nur gesagt, dass man das bedingt steuern kann, welche IP bevorzugt verteilt wird. Praktikabel ist das nicht wirklich, zumal es Software gibt, die stur den ersten Eintrag nimmt und den zweiten ignoriert.Liebe Grüße
Erik
Moin,
das mit einem DNS-Eintrag auf 2 IPs ist immer schwierig.
Stichwort DNS-Cache beim Client, dessen Router oder dessen Provider.
Das mit dem Routing im RZ ist die Königslösung.
Dafür braucht man noch nicht mal VPN.
Eine Software prüft alle 10 Sekunden ob die primäre IP erreichbar ist.
Kombiniert mit einer Portweiterleitungsregel.
Alternativ wäre auf DynDNS oder schlicht 2 Hostnamen möglich.
Der User hat einfach 2 Icons für die Einwahl. "Einwahl IP1" und "Einwahl IP2".
Das wäre auch eine Lösung für den Fall, dass die Leitung aktiv ist, aufgrund einer Störung aber keine Daten transportiert.
Stefan
das mit einem DNS-Eintrag auf 2 IPs ist immer schwierig.
Stichwort DNS-Cache beim Client, dessen Router oder dessen Provider.
Das mit dem Routing im RZ ist die Königslösung.
Dafür braucht man noch nicht mal VPN.
Eine Software prüft alle 10 Sekunden ob die primäre IP erreichbar ist.
Kombiniert mit einer Portweiterleitungsregel.
Alternativ wäre auf DynDNS oder schlicht 2 Hostnamen möglich.
Der User hat einfach 2 Icons für die Einwahl. "Einwahl IP1" und "Einwahl IP2".
Das wäre auch eine Lösung für den Fall, dass die Leitung aktiv ist, aufgrund einer Störung aber keine Daten transportiert.
Stefan
@StefanKittel
Gruß,
Dani
Das mit dem Routing im RZ ist die Königslösung.
Dafür braucht man noch nicht mal VPN.
Eine Software prüft alle 10 Sekunden ob die primäre IP erreichbar ist.
Kombiniert mit einer Portweiterleitungsregel.
ist eigentlich ne einfache Sache: zwei VMs die als Loadbalancer über eine Failover-IP verfügen. Über Layer4 bzw. 7 durch den VPN-Tunnel wird geprüft, ob Daten abrufbar sind. Schlägt dies fehl, wird der Node als Offline markiert und der Traffic geht automatisch durch den anderen Tunnel.Dafür braucht man noch nicht mal VPN.
Eine Software prüft alle 10 Sekunden ob die primäre IP erreichbar ist.
Kombiniert mit einer Portweiterleitungsregel.
Gruß,
Dani
Das Auslagern der betroffenen Dienst kommt nicht in Frage (da dies fast ein Großteil der Systeme bedeuten würde). Vor Ort gibt es eine gesamte Infrastruktur die redundant vorliegt (bis auf die Internetanbindung).
Es ist eine Standleitung mit entsprechender Reaktionszeiten. Das Problem ist, dass die Ausfälle zwiemal durch Dritte verursacht wurde (Durchtrennung der Leitungen, der geplante andere Provider war davon nicht betroffen) sowie durch Hardwareausfall. Die Behebung erfolgte zwar idR innerhalb der Zeiten, jedoch waren die Ausfälle doch zu oft, da sie nunmal auch tagsüber passieren.
Das war unter anderem ein Grund wieso ich daovn auch wenig halte, da auch Standordvernetzungen sowie automatisierte Dienste angebunden sind.
Die Lösung wurde von einem Anbieter angeboten der u.A. Rechenzentren betreibt und Managed Services u.A. für Unternehmen anbietet. Das Auslagern der Dienste würde aufgrund der Kostenlast die es bedeuten würde nicht in Frage kommen, da wir eine gesamte Infrastruktur vor Ort haben und die auch erst vor 2 Jahren gesamt modernisiert wurde. Angedacht war das auch die lokalen Firewalls durch den Anbieter managen zu lassen.
@Dani:
Hintergrund ist das die Hauptleitung (Glasfaser) bereits zweimal ausgefallen ist.
Das ist relativ. Das hängt a) vom Provider ab b) vom Produkt c) von den SLAs.Es ist eine Standleitung mit entsprechender Reaktionszeiten. Das Problem ist, dass die Ausfälle zwiemal durch Dritte verursacht wurde (Durchtrennung der Leitungen, der geplante andere Provider war davon nicht betroffen) sowie durch Hardwareausfall. Die Behebung erfolgte zwar idR innerhalb der Zeiten, jedoch waren die Ausfälle doch zu oft, da sie nunmal auch tagsüber passieren.
1. Mittels FQDN (Bsp. xyz.muster.de, zzz.muster.de,...) arbeiten und je FQDN die beiden IP-Adressen (eine IP aus dem Primärleitung, eine IP aus der Sekundärleitung) über die der Dienst verfügbar wäre hinterlegen. Die Idee entstammt von einem Dienstleister, der uns betreut.
Das geht auf Dauer nicht gut. Wann weiß ein Benutzer, wenn xyz.muster.de nicht erreichbar ist, ob es an seinem ISP bzw. WLAN Hotspot oder an euch liegt? Das führt aus Erfahrung heraus nur zur Verwirrung.Das war unter anderem ein Grund wieso ich daovn auch wenig halte, da auch Standordvernetzungen sowie automatisierte Dienste angebunden sind.
2. EInen VPN-Tunnel zwischen lokaler Firewall zu einer Firewall im Rechenzentrum aufbauen und die öffentlichen Dienste über den Tunnel routen. Bei Ausfall der Hauptleitung und VPN-Tunnel würde der andere Tunnel die Dienste übernehmen.
Dann würde ich die Services gleich ins RZ stellen und immer über einen VPN-Tunnel die Daten bereitstellen. Somit kannst du dir einiges an Komplexität, Nerven und Zeit sparen. Fällt Leitung a) wird der VPN-Tunnel erneut aufgebaut. Alternativ wird über beide ISP jeweils aktiv ein VPN-Tunnel aufgebaut und beim Ausfall ändert sich nur das Routing. Ist je nach Szenario ein Ticken schneller.Die Lösung wurde von einem Anbieter angeboten der u.A. Rechenzentren betreibt und Managed Services u.A. für Unternehmen anbietet. Das Auslagern der Dienste würde aufgrund der Kostenlast die es bedeuten würde nicht in Frage kommen, da wir eine gesamte Infrastruktur vor Ort haben und die auch erst vor 2 Jahren gesamt modernisiert wurde. Angedacht war das auch die lokalen Firewalls durch den Anbieter managen zu lassen.
