Standort-VPN neben dem ISP-Router ergänzen, ohne Gespräche zu unterbrechen

Lassen Sie die Internet- und Sprachrolle des ISP-Routers unangetastet, während ein zweites Gateway den privaten Pfad übernimmt. Führen Sie diese fünf Prüfungen durch, bevor Sie eine Route ändern.

Die meisten kleinen Standorte haben bereits eine Box, die Internet, DHCP und die Sprachleitung macht, und diese Box wird Ihren Standort-Tunnel nicht fahren. Ein zweites Gateway für den privaten Pfad hinzuzufügen funktioniert, sofern Sie vor dem ersten Kabelkontakt klären, wer welche Route besitzt. Das eigentliche Risiko ist nicht der Tunnel, sondern das stille Tauschen des Geräts, das die Telefone registriert hält. Arbeiten Sie die fünf Prüfungen der Reihe nach ab und halten Sie an, wo eine scheitert.

Notieren Sie die Rollen, die bereits funktionieren

Halten Sie Standard-Gateway, DHCP-Server, Resolver und das Gerät fest, das die Sprachregistrierung des Anbieters hält. In diesem Beispiel ist der ISP-Router 10.50.0.1, das neue Gateway sitzt auf 10.50.0.2, und der entfernte Standort ist 10.60.0.0/24. Nichts daran ändert die ersten drei Rollen, und genau das ist der Punkt. Prüfen Sie dann, ob die zweite Box den benötigten Tunnel wirklich terminieren kann: Protokoll, erwarteter Durchsatz und ob sie Firmware- oder Paketaktualisierungen erhält. Ein Gerät mit VPN-Logo und ohne Update-Weg ist eine Last, kein Zugewinn.

Wenn Sie nicht sagen können, wer den Sprachdienst besitzt, hören Sie auf. Den Router mit einer Registrierung ohne Rückfallplan zu tauschen, macht aus einem VPN-Projekt einen Telefonausfall.

Geben Sie dem neuen Gateway eine Adresse und eine Aufgabe

Reservieren Sie seine LAN-Adresse außerhalb des DHCP-Pools, damit sie nach einem Neustart nicht wandert, und geben Sie ihm keine eigene Standardroute, außer Sie wollen es als Internetpfad. Seine Aufgabe ist, den Tunnel zu halten und für entfernte Präfixe zu antworten. Auf den LAN-Hosts, die den entfernten Standort erreichen müssen, belegen Sie, welchen Pfad sie jetzt nehmen und welchen Sie nach der Änderung wollen; dieselben zwei Befehle vorher und nachher sind der billigste Beweis.

ip route get 10.60.0.55
ip neigh show 10.50.0.2
traceroute -n 10.60.0.55

Wenn die Abfrage den ISP-Router liefert und der Traceroute am Internetrand stirbt, hat der Host noch keinen entfernten Pfad, was zu erwarten ist. Kommt etwas Unerwartetes zurück, klären Sie das zuerst, denn jeder spätere Schritt setzt diese Basis voraus.

Wählen Sie, wer die Route zum entfernten Präfix besitzt

Option A ist der ISP-Router: Er hält eine statische Route für 10.60.0.0/24 zum Gateway, und jeder Host folgt wie bisher seinem Standard-Gateway. Option B ist pro Host: Nur die Maschinen, die den entfernten Standort brauchen, bekommen eine explizite Route über 10.50.0.2, alles andere bleibt unberührt. A ist bei vielen Hosts sauberer, verlangt aber meist, dass der Anbieter-Router eine statische Route annimmt, was manche nicht tun. B braucht keine Mitwirkung des Anbieters, lässt aber die Host-Konfiguration bei Ihnen, passt also zu einem kleinen freigegebenen Satz von Maschinen.

In beiden Fällen muss die Rückrichtung existieren. Kommt eine entfernte Antwort am Gateway an und leitet das Gateway sie direkt an einen LAN-Host, umgeht der Verkehr den Firewall-Zustand, den der ISP-Router auf dem Hinweg hielt. Ist das Gateway nicht der Standardrouter des LAN, ist diese Asymmetrie eine Designentscheidung, kein Fehler, den man ignorieren darf.

ip route add 10.60.0.0/24 via 10.50.0.2 dev eth0
ip route get 10.60.0.55 from 10.50.0.77

Machen Sie den Eintrag über den Konfigurationseigner des Hosts dauerhaft, nicht über ein Anmeldeskript. Eine Route, die erst nach einer Anmeldung existiert, versagt beim ersten Neustart der Maschine aus einem unabhängigen Grund.

Sorgen Sie für einen erreichbaren eingehenden Endpunkt

Das Gateway braucht eine Adresse, die der entfernte Standort erreichen kann. Hinter dem ISP-Router heißt das Portweiterleitung oder DMZ-Eintrag, und beides hängt davon ab, dass der Anbieter den Verkehr wirklich liefert. Eine lokale Weiterleitung überwindet kein Carrier-Grade-NAT auf Anbieterseite. Gibt der Anbieter keinen erreichbaren Endpunkt, drehen Sie die Richtung um: Lassen Sie beide Standorte zu einem Hub initiieren, den Sie kontrollieren. Das ist ein gültiges Design, fügt aber eine dritte Abhängigkeit für Weiterleitung, Vertrauen und Verfügbarkeit hinzu, und dynamisches DNS ersetzt sie nicht.

Bestätigen Sie die Weiterleitung mit einem Mitschnitt am Gateway, nicht mit einer Website, die Ports scannt. Scanner melden den Port geschlossen, bis der Listener gebunden ist, und eine Weiterleitung, die nie Verkehr liefert, sieht von außen aus wie ein geschlossener Port.

Akzeptieren Sie den privaten Dienst und die Sprachleitung zusammen

Testen Sie den beabsichtigten Betrieb von einem LAN-Host, mit privatem DNS und den eigenen Zugangsdaten der Anwendung. Ein gerouteter Tunnel lässt entferntes Browsen nicht wie ein lokales Ethernet-Segment aussehen, deshalb brauchen Erkennung und Namensauflösung eigene Regelungen.

curl -sS -o /dev/null -w '%{http_code}\n' https://files.example.net
ping -c 3 10.60.0.55

Bestätigen Sie danach, dass normaler Internetzugang vom selben Host weiter funktioniert und die Telefone weiter registriert sind; diese zwei Prüfungen fangen eine versehentliche Änderung der Standardroute, den häufigsten Weg, auf dem dieses Projekt etwas beschädigt, das es nie anfassen wollte. Schließen Sie mit einer schriftlichen Wiederherstellungsnotiz: welches Gerät welche Rolle hält, die reservierten Adressen und wie sich die Route zum entfernten Präfix in einem Schritt entfernen lässt. Ein privater Pfad, der sich sauber zurückziehen lässt, ist mehr wert als einer, der nur heute funktioniert.

Ähnliche Artikel