Welche Komponente besitzt wirklich ein OpenVPN-Routenlimit?
Ein Routenlimit kann zur OpenVPN-Engine, zum NetworkManager-Plugin oder zum Server gehören. Nennen Sie den Eigentümer, bevor Sie ein Profil bearbeiten oder eine Zahl erhöhen.
Ein Profil mit zweihundert Routen funktioniert auf einer Maschine und installiert auf einer anderen nur vierzig. Die Engine, die Integration, die sie startet, und der Server, der sie füttert, reden alle mit, und jede Stelle kann die Liste an einem anderen Punkt beenden. Wer den Fehler als ein einziges Limit liest, landet in der falschen Datei. Der Mechanismus besteht aus drei Stufen, und die Stufe, die gestoppt hat, hinterlässt sichtbare Spuren, wenn man weiß, wonach man suchen muss.
Drei Stufen, drei verschiedene Limits
Zuerst liest die Engine die Option und entscheidet, ob diese Version sie versteht. Dann installiert die Integration, was die Engine meldet, und ihr eigener Code kann die Liste begrenzen oder umformen. Schließlich entscheidet der Server, wie viele Routen er an eine bestimmte Identität ausliefert, bevor eine der beiden Client-Stufen überhaupt etwas sieht. Drei Stufen, drei Obergrenzen, und nur eine davon ist die Zahl im Profil.
Eine angehobene Obergrenze ändert an den anderen nichts. Eine abgelehnte ausgelieferte Route kann eine Richtlinienentscheidung auf dem Server sein, eine Überlappung, die der Client aufgelöst hat, oder ein Installationslimit, das den Überschuss verworfen hat. Für jeden dieser Fälle gibt es eine andere Lösung.
Trennen Sie die drei, bevor Sie irgendetwas messen. Ein Parserfehler nennt ein Token, ein Installationslimit hinterlässt eine kurze Routentabelle, und eine Richtlinienentscheidung hinterlässt gar nichts. Die Spuren zeigen Ihnen, welche Stufe Sie zuerst prüfen sollten.
| Stage | Who decides | What you can see |
|---|---|---|
| Parse | Client engine | An error naming the option |
| Install | Activation owner | A route count below the pushed count |
| Offer | Server policy | A route absent from the pushed list |
Der Parser spricht zuerst
Eine unbekannte Option scheitert laut und früh, und der Fehlertext nennt das Token. Das ist die am leichtesten zu erkennende Stufe: Vergleichen Sie die genaue Meldung mit der installierten Engine-Version, denn eine Option, die in einem Release hinzukam, ist in dem davor unbekannt. Ein Profil, das aus einer neueren Installation kopiert wurde, ist die übliche Ursache dieser Abweichung. Der Parser ignoriert eine Anweisung, die er nicht kennt, niemals stillschweigend.
Eine akzeptierte Option sagt nichts über das Ergebnis aus. Das Parsen gelingt, und trotzdem kann die Liste vom Installer gekürzt werden oder vom Server nie angeboten worden sein. Behandeln Sie einen sauberen Parse als Erlaubnis weiterzumachen, nicht als Beweis.
Notieren Sie die Versionszeichenkette aus dem Binary, das tatsächlich gelaufen ist, nicht aus der Vorstellung des Paketmanagers davon, was installiert sei. Diese beiden sind sich häufiger uneinig als erwartet.
Der Installer hat seine eigene Obergrenze
Die Komponente, die die Aktivierung verantwortet, kann ein NetworkManager-Plugin und nicht das Engine-Binary sein, und sie kann ihr eigenes Limit durchsetzen, bevor irgendein Tunnel existiert. Ihr Editor zeigt möglicherweise ein Feld, das die laufende Engine nie liest, oder liest ein Feld, das der Editor nicht anzeigt. Beide Situationen wirken von außen wie ein Client-Fehler. Keine von beiden wird durch Bearbeiten des Profils behoben.
Zählen Sie, was angekommen ist, statt was konfiguriert wurde. Der Befehl ip route show dev tun0 listet die installierten Routen auf, und ein Vergleich dieser Anzahl mit der ausgelieferten Liste trennt eine verworfene Route von einer, die nie gesendet wurde. Eine Anzahl, die zur Auslieferung passt, verschiebt den Verdacht zurück zum Server.
Ein Shell-Wrapper um das Engine-Binary, der eine größere Zahl erzwingen soll, verschleiert Upgrades und macht das Zurückrollen zum Rätselraten. Er versteckt außerdem das echte Limit vor jedem, der die Konfiguration als Nächstes liest.
Der Server entscheidet, was Ihnen angeboten wurde
Eine Richtlinie pro Client kann die Liste verkleinern, bevor sie übertragen wird. Eine client-spezifische Datei kann Routen für eine Identität hinzufügen, oder eine Gruppenrichtlinie kann sie weglassen, und der Client kann eine gefilterte Route nicht von einer unterscheiden, die nie definiert wurde. Wegen dieser Unklarheit zählt der Eintrag auf dem Server. Fragen Sie nach der effektiven Auslieferungsliste für diese Identität, nicht nach der Vorlage.
Vergleichen Sie den Servereintrag mit der empfangenen Liste. Die Lücke dazwischen ist die Richtlinienschicht, und sie ist meist kleiner, als das Profil vermuten lässt.
Wo das Design es erlaubt, fassen Sie zusammenhängende Netze zusammen und löschen Sie veraltete Einträge. Weniger, größere Routen lösen mehr Fälle als eine höhere Obergrenze.
Ändern Sie die Zahl an der richtigen Stelle
Nutzen Sie die dokumentierte Einstellung der Komponente, die das Limit wirklich verantwortet. Fehlt das Feld im Plugin, prüfen Sie, ob das Plugin älter ist als die Funktion oder ob ein anderes Backend die Routen verantwortet. Dokumentieren Sie dann die Versionen von Engine, Plugin und Server neben dem gewählten Wert. Das nächste Upgrade öffnet die Frage erneut, und erst die Notiz macht sie beantwortbar.
Testen Sie nach jedem Upgrade einer der drei Stellen erneut. Ein an der richtigen Stelle angehobenes Limit verschiebt sich trotzdem, wenn sich die Komponente ändert, die es durchsetzt. Der Versionsdatensatz ist das Einzige, was diese Verschiebung vorhersagbar macht.