Wenn ein Fernzugriffsclient als Filial-Gateway fungieren muss
Ein Filialsubnetz durch einen Fernzugriffsclient weiterzuleiten, ist ein Routing-Vertrag. Bestätigen Sie, dass das Produkt diese Rolle unterstützt, und übernehmen Sie dann Adressierung und Wiederherstellung.
Ein Laptop, der mit einem VPN verbunden ist, erreicht die Zentrale. Der Drucker und der Dateiserver am selben Schreibtisch erreichen sie nicht, weil nichts ihre Pakete in diesen Tunnel weiterleitet oder die Antworten zurückbringt. Den Client in ein Filial-Gateway zu verwandeln, ist eine Routing- und Zuständigkeitsentscheidung, bevor es eine Konfigurationsentscheidung ist. Der Protokollname auf der Schachtel beantwortet nicht, ob diese Rolle unterstützt wird.
Was das Protokolletikett Ihnen nicht sagt
OpenVPN dokumentiert ein Standort-zu-Standort-Design, bei dem ein Connector ein ganzes Subnetz weiterleitet, und Access Server setzt es mit einer Gateway-Rolle und explizitem Routing um. Ein anderes Produkt, das als SSL-VPN vermarktet wird, bietet möglicherweise nur Fernbenutzerfunktionen, ohne unterstützten Weg, ein Netzwerk hinter dem Client anzukündigen. Auch die Version zählt, denn eine Funktion in einer Ausgabe ist kein Versprechen für eine andere. Lesen Sie die Implementierung, die Sie tatsächlich betreiben, und behandeln Sie ein Rezept für ein anderes Produkt als Hinweis, nicht als Entwurf.
Die zuerst zu klärende Frage ist, ob der VPN-Eigentümer die Weiterleitungsrolle überhaupt unterstützt. Wenn nicht, macht keine clientseitige Routingkonfiguration sie unterstützt.
Der Vertrag hat zwei Seiten: Filiale und Zentrale
Auf der Filialseite verantwortet ein Host Weiterleitung, Filterung und Wiederherstellung. Er braucht einen bewussten Pfad von jedem Filialgerät, und die äußere VPN-Verbindung muss über das zugrunde liegende Netzwerk erreichbar bleiben, auch während der Tunnel ausgefallen ist. Auf der Seite der Zentrale muss jemand das Filialsubnetz definieren, die Identität des Gateways akzeptieren und bestimmte Ressourcen zulassen. Keine Hälfte funktioniert allein.
Der Rückweg ist der Teil, der übersprungen wird. Eine Tunneladresse für den Client kündigt das Subnetz dahinter nicht an, daher brauchen die Router der Zentrale eine Route, die für dieses Präfix auf das VPN-Gateway zeigt.
In einem gerouteten Entwurf leitet der Konzentrator Pakete für das Filialpräfix weiter, und das Routing des übergeordneten LAN weiß, wie Antworten dorthin zurückgehen. In einem übersetzten Entwurf wird die Quelle, die die Zentrale sieht, umgeschrieben, was eine Rückroute ersparen kann, aber verbirgt, welche Filialmaschine den Verkehr gesendet hat. Dieser Kompromiss gehört ins Designdokument, weil Anwendungsprotokolle und Zugriffsregeln die Identität pro Gerät verlieren, sobald die Übersetzung im Spiel ist.
Geroutet oder übersetzt: den Rückweg bewusst wählen
Wählen Sie geroutet, wenn Identität pro Gerät und Richtlinie pro Host wichtig sind und Sie die Rückroute auf jedem relevanten Router pflegen können.
Wählen Sie übersetzt, wenn Sie keine Routen hinzufügen können, aber akzeptieren, dass die Zentrale eine Quelladresse sieht. Gemischte Entwürfe gibt es, und sie sind schwerer zu durchdenken, also notieren Sie, welche Präfixe geroutet und welche übersetzt sind. Prüfen Sie die Wahl dann mit einem Mitschnitt an beiden Enden, statt dem Tunnelstatus zu vertrauen.
Eine nützliche Prüfung ist asymmetrisch: Fordern Sie eine Ressource von einem Filialgerät an und bestätigen Sie dann, dass die Antwort die Zentrale in Richtung Filialpräfix verlässt. traceroute -n 10.60.4.20 von einem Host in der Zentrale zeigt, ob dieser Pfad über das VPN-Gateway geht.
Betreiben Sie es wie Infrastruktur, nicht wie eine Anmeldung
Entscheiden Sie, wie das Gateway startet, sich authentifiziert, aktualisiert und wiederherstellt, wenn niemand angemeldet ist. Erneuerung von Anmeldedaten, Mehrfaktorabfragen, Schlafverhalten und die Frage, wer reagiert, wenn die Filiale den Zugriff verliert, werden alle zu Betriebsfragen. Mehrere Personen, die einen Netzwerkpfad teilen, dürfen nicht die persönlichen Privilegien des Gateway-Benutzers erben, daher brauchen Ressourcenautorisierung, Protokollierungsumfang und Fehlerrichtlinie einen benannten Eigentümer. Ein Konto zu teilen, um die Registrierung jedes Geräts zu vermeiden, ist kein Entwurf.
Vergleichen Sie die Anordnung mit einem unterstützten Standort-Gateway unter denselben Anforderungen, bevor Sie sich festlegen. Ein alter Desktop-Rechner ersetzt weder Wartung noch Wiederherstellung, und der Gebrauchtpreis beschreibt nicht die Betriebskosten.
Prüfen Sie die vorgesehenen Filialanwendungen, ihren Rückverkehr und ein verweigertes Ziel im Rahmen eines genehmigten Plans. Erfolg sieht wie ein eigener Netzwerkdienst mit benannter Filialidentität und ausdrücklicher Richtlinie aus, nicht wie ein Clientfenster mit der Anzeige Verbunden.