Bringt ein VPN-Client auf Ihrem Webserver dessen Antworten durcheinander?

Die Site lädt von einem Laptop im selben Netzwerk und läuft von überall sonst in eine Zeitüberschreitung, und der Host betreibt außerdem einen VPN-Client für seinen eigenen ausgehenden Verkehr. Diese Kombination erzeugt einen bestimmten Fehler: Die eingehende Verbindung kommt an, die Antwort verlässt den Host über den falschen Pfad, und der Client draußen sieht nie eine Antwort. Beide Hälften erscheinen in derselben Paketaufzeichnung, daher ist die Reihenfolge der Ereignisse der Teil, der es wert ist, gelesen zu werden.

Eine quellenbasierte Routing-Regel behebt oft das Symptom. Sie nimmt außerdem meist mehr Verkehr aus als die Site, die sie veranlasst hat, und genau das ist der Teil, den man verstehen sollte, bevor man die Regel speichert.

Das Symptom: lokal antwortet er, von außen nicht

Innerhalb des Netzwerks muss die Antwort den Tunnel nicht überqueren, also lädt die Seite, und der Dienst wirkt gesund. Von außen erreicht die Anfrage den Host, und die Antwort wird in das VPN geleitet, wo das entfernte Ende keinen Grund hat, sie anzunehmen. Der Browser sieht eine Zeitüberschreitung statt einer Ablehnung, was die Signatur eines einseitigen Pfads und nicht eines geschlossenen Ports ist.

Bestätigen Sie die Form, bevor Sie das Routing ändern: Der Listener läuft, die lokale Anfrage gelingt, und die externe Anfrage erzeugt überhaupt keine Antwort. Diese drei Beobachtungen deuten zusammen auf den Rückweg und nicht auf die Konfiguration des Webservers hin. Eine so saubere Asymmetrie ist nützlicher als jede Protokollzeile, weil sie den Listener ausschließt, bevor Sie eine einzige Fehlermeldung lesen.

Halten Sie während der Arbeit einen unabhängigen Verwaltungsweg offen. Eine Regel, die Ihre eigene SSH-Sitzung zerstört, verwandelt eine zehnminütige Korrektur in einen physischen Besuch.

Was ein Quellenselektor tatsächlich trifft

Im Linux-Policy-Routing trifft eine Regel wie from 192.168.50.2 Pakete, deren Quelle diese Adresse ist. Sie kodiert nicht, dass das Paket ein Gespräch fortsetzt, das über den Heimrouter hereinkam, und sie weiß nicht, welcher Prozess es erzeugt hat. Die Adresse in diesem Beispiel ist illustrativ; setzen Sie die Adresse ein, die Ihr Host tatsächlich verwendet. Behandeln Sie die Zeile als eine Aussage über Adressen und nichts weiter.

Wenn die ausgewählte Tabelle eine gewöhnliche Standardroute liefert, kann jedes Paket mit dieser Quelle dieselbe Ausnahme nehmen. Ein anderer Dienst, der an dieselbe Adresse gebunden ist, erbt sie, und eine Anwendung, die sich bewusst an diese Adresse bindet, erbt sie ebenfalls. Die Referenz zu Policy-Regeln führt Quelle, Ziel, Protokoll, Port, Mark und Priorität als getrennte Selektoren auf, was daran erinnert, dass die Quelle allein der gröbste verfügbare ist.

Die Priorität entscheidet über das Ergebnis. Lookups laufen der Reihe nach, und die erste Tabelle, die ein Ergebnis liefert, kann die Suche beenden, sodass eine zu früh platzierte Regel eine spezifischere Route verbergen kann, die eine spätere Tabelle geliefert hätte. Lesen Sie die gesamte geordnete Liste statt der einen Zeile, die Sie hinzugefügt haben. Eine Regel, die nie trifft, kostet nichts, während eine, die zu früh trifft, stillschweigend alles dahinter verändert.

Prüfen Sie den Rückweg und den Verkehr, den Sie nicht beabsichtigt haben

Lesen Sie die Regeln und die Tabellen und fragen Sie dann den Kernel, welche Route ein bestimmtes Quell-Ziel-Paar nehmen würde. Vom Host selbst zu testen ist nicht dasselbe wie von außen zu testen, also tun Sie beides.

ip rule show
ip route show table 100
ip route get 203.0.113.44 from 192.168.50.2
ss -ltnp '( sport = :443 )'

Akzeptieren Sie dann eine neue externe Verbindung und getrennt davon eine Anfrage, die weiterhin über das VPN hinausgehen muss. Wenn die zweite jetzt direkt hinausgeht, ist die Ausnahme breiter als das Problem, das Sie gelöst haben, und der Test, auf den es ankommt, ist derjenige, den Sie nicht ändern wollten.

Eine öffentliche Adressprüfung im Browser meldet nur die Anfragen, die dieser Browser gestellt hat. Sie sagt nichts über die Antworten des Webservers, über die Quellenwahl einer anderen lokalen Anwendung oder darüber, was mit Verwaltungsverkehr nach der nächsten VPN-Wiederverbindung geschieht.

Entscheiden Sie, wie eng die Ausnahme sein kann

Zwei Entwürfe sind vertretbar, und sie sollten bewusst gewählt werden. Wenn der Host existiert, um diesen Dienst zu veröffentlichen, und sein ausgehender Verkehr unwichtig ist, ist eine dedizierte lokale Adresse mit einer reinen WAN-Policy eine vernünftige Regelung, sofern Sie den gesamten Umfang akzeptieren. Wenn nur bestimmte eingehende Verbindungen qualifizieren sollen, ist die Adressauswahl zu grob, und ein verbindungsbewusster Entwurf gehört davor.

Notieren Sie den Vertrag, auf den Sie sich verlassen: das öffentliche Mapping, die Hostadresse, an die die Anfrage geliefert wird, und den Pfad, den die Antwort nehmen soll. Ein eingehender Dienst, der über einen VPN-Anbieter veröffentlicht wird, ist ein anderer Vertrag als einer, der über einen Heimrouter veröffentlicht wird, und eine aus einem Beispiel kopierte Ausnahme ist für das andere oft falsch.

Bewahren Sie die Policy in der Komponente auf, die das Routing besitzt, statt einen Befehl in eine Startdatei zu kleben. Regelreihenfolge, Aufräumen nach einer Netzwerkänderung und Wiederholung nach einem Neustart müssen alle überleben, und eine ungetestete Startdatei versagt gewöhnlich in dem Moment, in dem Sie nicht hinsehen. Schließen Sie mit dem Akzeptanzergebnis ab, das Sie verteidigen können: eine veröffentlichte Site wiederhergestellt und ein unabhängiger Fluss unverändert.