Braucht ein VPN-Laptop IP-Weiterleitung, um schneller zu werden?
Weiterleitung reicht Pakete zwischen Schnittstellen weiter; einen lokalen Browser macht sie nicht schneller. Trennen Sie die Client-Rolle von der Gateway-Rolle, bevor Sie eine Regel erweitern.
Den Laptop zum Router zu machen ist ein beliebter Weg, das falsche Problem zu lösen. Weiterleitung existiert, damit eine Maschine Pakete weiterreichen kann, deren Ziel nicht sie selbst ist, und sie hat keine Meinung dazu, wie schnell ein Browser auf derselben Maschine eine Seite lädt. Die beiden Wege sehen nur deshalb gleich aus, weil beide den Verkehr durch einen Tunnel schicken. Trennen Sie sie einmal, und ein Großteil der Ratschläge zum Aktivieren der Weiterleitung oder zum Öffnen der Firewall beschreibt am Ende eine Topologie, die Sie nicht haben.
Zwei Paketwege, die vom Schreibtisch aus identisch aussehen
Der Browser auf dem Laptop erzeugt seine eigene Anfrage. Der Host wählt die Tunnelroute, der Clientprozess verpackt das Paket und schickt es zum Peer, und die Antwort kommt zur Anwendung zurück. Nichts in dieser Abfolge kreuzt eine Weiterleitungsentscheidung, weil diese Maschine sowohl Quelle als auch Ziel des Gesprächs ist.
Setzen Sie nun ein anderes Gerät auf ein bewusst konfiguriertes Ethernet-Segment und machen Sie den Laptop zu dessen Standard-Gateway. Dieses Gerät startet die Anfrage, der Laptop empfängt ein Paket, das woandershin adressiert ist, und der Kernel muss entscheiden, ob er es weiterreicht. Das ist die Weiterleitungsrolle, und sie bringt Voraussetzungen mit, die die Client-Rolle nie brauchte: einen erlaubten Transitweg, Routen auf beiden Seiten und einen Rückweg, der noch funktioniert, wenn Übersetzung Teil des Entwurfs ist.
| Role | Who originates the traffic | What has to be true |
|---|---|---|
| Client only | The laptop itself | Tunnel route, working resolver, supported profile |
| Gateway | Another device | Forwarding enabled, permitted transit, routes both ways, return-path decision |
Was ip_forward tatsächlich ändert
Die IPv4-sysctl-Dokumentation des Kernels beschreibt ip_forward als den Schalter, der einen Host Pakete zwischen Schnittstellen weiterleiten lässt. Er ist kein schneller Weg für Verkehr, den der Host selbst erzeugt hat, und keine Lesart dieses Parameters macht einen lokalen Browser schneller. Wenn überhaupt, fügt Weiterleitung einer Maschine Zustand und Richtlinie hinzu, die vorher weniger Arbeit leistete.
Dieselbe Dokumentation warnt, dass das Ändern des Werts andere IPv4-Parameter auf ihre Host- oder Router-Standardwerte zurücksetzt. Das macht den Schalter zu einem Konfigurationsereignis statt zu einer Probe: abgestimmte Einstellungen können unter Ihnen zurückfallen, und die Änderung kann für eine Regression verantwortlich sein, die niemand ihr zuschreiben würde. Es bedeutet auch, dass der Schalter einmal, bewusst, von demjenigen gesetzt werden sollte, der die Gateway-Rolle besitzt. Ihn während einer Untersuchung von Langsamkeit umzulegen ist der eine Fall, in dem die Nebenwirkung garantiert mit dem Symptom verwechselt wird.
Drei Firewall-Fragen, die nicht dieselbe Frage sind
Einen VPN-Listener zuzulassen, die Dienste zuzulassen, die der Laptop ausführt, und Verkehr zuzulassen, der durch den Laptop läuft, sind drei getrennte Berechtigungen. Die erste lässt einen Peer einen Daemon erreichen, die zweite legt etwas Lokales offen, und die dritte macht die Maschine zum Transit für jemand anderen. Jede hat einen anderen Umfang, und die letzte ist weit breiter als die Antworten, die eine gewöhnliche ausgehende Anwendung braucht.
Wenn ein bestimmter Fluss blockiert ist, benennen Sie seine Quelle, sein Ziel, seine Richtung und den Richtlinieneigentümer, bevor Sie eine Regel ändern. Eine enge Regel für diesen Fluss ist eine Korrektur; alles auf der Tunnelschnittstelle zu akzeptieren ist eine Richtlinienänderung, die zufällig die Korrektur enthält. Ein Browser, der danach funktioniert, beweist, dass der Fluss funktioniert, nicht dass die breite Regel nötig war.
Messen Sie erst, wenn der Weg korrekt ist
Messen Sie mit demselben Ziel, derselben Last und vergleichbaren Bedingungen und ändern Sie jeweils eine Variable. Ein Test, der eine Weiterleitungsänderung, eine Firewall-Erweiterung und eine kopierte Cipher-Einstellung bündelt, liefert eine Zahl und keine Erklärung, weil nichts darin sagt, welche der drei das Ergebnis bewegt hat.
Halten Sie Routen- und Resolver-Fehler ganz aus dem Leistungsgespräch heraus. Ein Name, der langsam aufgelöst wird, ist kein Durchsatzproblem, und eine Übertragung, die bei einer festen Größe stockt, ist meist eine MTU-Frage und kein Ratenlimit. Notieren Sie, welche der drei Sie tatsächlich beobachtet haben, bevor Sie irgendwelche Zahlen vergleichen. Sonst erbt der nächste Leser eine Messung, die das Falsche misst, und eine Änderung, die niemand rechtfertigen kann.
Beschreiben Sie die Topologie, die Sie haben, nicht das Etikett auf dem Client
Ein Laptop, der seine Verbindung teilt, ein geroutetes Containernetz hostet oder Verkehr für eine virtuelle Maschine trägt, ist ein Gateway, wie auch immer die Software sich nennt. Das Wort Client beschreibt, wie der Tunnel konfiguriert ist, nicht ob Pakete an jemand anderen weitergereicht werden.
Machen Sie die Rolle im Betriebshandbuch ausdrücklich: was Verkehr erzeugt, was die Maschine durchqueren muss und um welche der beiden es in der aktuellen Aufgabe geht. Aktivieren Sie die Gateway-Rolle, wenn sie zum unterstützten Plan gehört, nicht als unerklärte Geschwindigkeitsanpassung auf eine Topologie, die nie eine brauchte.