Wohin gehört die Route in OpenVPN: zum Client oder zum Server?
Eine nackte Route in der Serverkonfiguration ändert den Server, nicht den Client. Wählen Sie die Clientdatei, einen globalen Push oder einen Push pro Client, und prüfen Sie, was angekommen ist.
Sie fügen route 10.60.0.0 255.255.255.0 der Serverkonfiguration hinzu, starten neu, verbinden einen Laptop erneut, und das Subnetz ist von diesem Laptop aus weiterhin nicht erreichbar. Die Zeile wurde akzeptiert, der Dienst startete sauber, und im Protokoll sieht nichts falsch aus. Was geschah, ist, dass die Route auf der Maschine installiert wurde, die Sie bearbeitet haben: Das Gateway glaubt nun, dieses Präfix erreichen zu können, während dem Client nichts mitgeteilt wurde. Die Platzierung ist die ganze Frage, und es gibt vier Orte, an denen dieselbe Zeile leben kann.
Die vier Orte und wer jeweils beliefert wird
Eine Route kann durch die eigene Konfiguration des Clients hinzugefügt, jedem Client über einen globalen Push angeboten, einem einzelnen Client über eine clientbezogene Datei angeboten oder in den eigenen Routingkontext des Servers geschrieben werden.
Diese vier Fälle verwenden nahezu identische Syntax und erzeugen völlig unterschiedliche Ergebnisse. Die ersten drei beeinflussen, was ein Client in den Tunnel sendet; der vierte beeinflusst, wie der Server ein Netzwerk erreicht, was nützlich ist, wenn der Server selbst einen Pfad braucht, und schädlich, wenn er mit Verteilung verwechselt wird.
Entscheiden Sie, welchen der vier Sie wollen, bevor Sie die Zeile schreiben, und bestätigen Sie dann den Empfänger.
| Placement | Effect | Receiver |
|---|---|---|
| Client profile route | Installed by the client at connect | That client only |
Global push "route ..." | Sent to every client that accepts pushed options | All pulling clients |
| Client-specific push | Sent to the matching client context | One identity |
| Server config route, no push | Added to the server's own table | The gateway itself |
Warum die nackte Serverroute Leute überrascht
Die Serverkonfiguration ist der Ort, an dem Administratoren zuerst nachsehen, und eine Routendirektive dort liest sich wie eine Aussage über das VPN-Netz. Ist sie nicht. OpenVPN behandelt sie als lokale Routeninstallation auf der Maschine, auf der der Daemon läuft, also genau dieselbe Art von Änderung, die Sie mit ip route vornehmen und dann vergessen würden.
Verteilung erfordert, dass die Route gepusht wird, und Pushen erfordert, dass der Client zieht. Ein Client, der mit deaktivierten gezogenen Optionen gestartet wurde, ignoriert das Angebot völlig. Prüfen Sie beide Enden dieses Handschlags, bevor Sie die Serverdatei umschreiben, denn das Serverprotokoll wird sich nicht beschweren: von seiner Seite wurde das Angebot gesendet. Eine akzeptierte Route greift außerdem erst beim nächsten Verbindungsaufbau, niemals in der Sitzung, in der Sie sich bereits befinden.
Sobald Sie die beiden als getrennte Vorgänge sehen, ist der Fehler nicht mehr rätselhaft: Der Server erreicht das Präfix, der Client nicht, und beide Aussagen sind gleichzeitig wahr.
Dateien pro Client und die Identität, zu der sie passen
Eine clientbezogene Datei wird nach der Identität benannt, die der Server authentifiziert hat, standardmäßig der Common Name des Zertifikats. Ein freundlicher Verbindungsname in einem Desktop-Client ist nicht dieser Wert, und eine Abweichung erzeugt eine Datei, die nie gelesen wird.
Prüfen Sie das Verzeichnis, das der Server tatsächlich verwendet, und bestätigen Sie dann, dass der Dateiname exakt mit der authentifizierten Identität übereinstimmt, einschließlich Groß- und Kleinschreibung.
grep -n 'client-config-dir' /etc/openvpn/server/server.conf
ls -l /etc/openvpn/ccd/Innerhalb dieser Datei muss die Route weiterhin gepusht werden, denn der clientbezogene Kontext ist eine Menge von Optionen, die auf die Sitzung dieses Clients angewendet werden, keine lokale Routingtabelle. Eine nackte Route dort hat dasselbe Problem wie eine nackte Route in der globalen Datei.
Die eigene Datei des Clients und das Werkzeug, das sie verwaltet
Eine Route, die in die Clientkonfiguration eingetragen wird, wird beim Verbinden dieses Clients installiert und beim Trennen entfernt, was der richtige Lebenszyklus für ein statisches Ziel ist.
Wenn ein Netzwerkmanager das Profil verwaltet, importiert er diese Optionen möglicherweise einmal und behält dann seine eigene Kopie. Die heruntergeladene Datei später zu bearbeiten ändert nichts, was eine häufige Ursache für "die Route ist da, gilt aber nicht" ist.
Prüfen Sie das aktive Profil statt der heruntergeladenen Datei und prüfen Sie die importierten Einstellungen, die der Manager anzeigt. Verbinden Sie sich dann und fragen Sie das System, welchen Weg eine bestimmte Adresse nutzt, statt anzunehmen, der Tunnel habe gewonnen, weil die Route in einer Textdatei stand.
Auf dem Client prüfen, dann den Rückweg kontrollieren
Fragen Sie die eigene Routingtabelle des Clients nach dem Ziel, nicht die des Servers. Eine Suche nach einem einzelnen Host innerhalb des Präfixes genügt, um Schnittstelle und nächsten Hop anzuzeigen, die verwendet werden.
ip route get 10.60.0.10Zeigt die Suche auf den Tunnel, hat die Verteilung funktioniert und das verbleibende Problem liegt anderswo. Zeigt sie auf das Standardgateway, wurde die Route nicht installiert, von einer clientseitigen Option gefiltert oder gehört zu einem Profil, das der Client nicht verwendet.
Nehmen Sie an, die Verteilung habe funktioniert, und es antwortet trotzdem nichts: Prüfen Sie dann Weiterleitung auf dem Gateway, die Rückroute der Gegenseite und jede Firewall dazwischen. Eine Route wählt einen Weg, sie gewährt keinen Zugang.