Welche Quelladresse protokolliert NGINX für einen VPN-Client?

Entscheiden Sie, was NGINX neben OpenVPN auf einem Host sieht: eine innere Tunneladresse, eine öffentliche Ausgangsadresse oder einen weitergeleiteten Peer, je nachdem welchen Pfad die Anfrage genommen hat.

In einem NGINX-plus-OpenVPN-Setup auf demselben Host tauchen drei Clientadressen auf, eine für jeden Pfad, den eine Anfrage nehmen kann. Ein Browser, der die Tunneladresse anspricht, ein Browser, der die öffentliche Adresse anspricht, und ein Programm, das über den Internetpfad des Gateways hinausgeht, sehen am lauschenden Socket alle unterschiedlich aus. Entscheiden Sie, welchen Pfad Sie betrachten, bevor Sie die Logzeile interpretieren. Die Entscheidung hängt vom Ziel ab, das der Client verwendet hat, von der Ausnahme, die er für den äußeren VPN-Endpunkt hält, und davon, ob unterwegs etwas das Paket übersetzt.

Nach Ziel entscheiden, nicht nach dem Benutzer

Beginnen Sie bei der Adresse, an die die Anfrage gesendet wurde, denn diese Adresse wählt den Pfad. Eine Anfrage an die Tunneladresse des Hosts kommt auf der Tunnelschnittstelle an, mit der inneren Adresse des Clients als Quelle. Eine Anfrage an die öffentliche Adresse des Hosts kommt normalerweise auf der internetzugewandten Schnittstelle mit der öffentlichen Adresse des Clients an, selbst wenn dasselbe Notebook in diesem Moment einen Tunnel aufgebaut hat. Die Zugehörigkeit zum VPN-Pool ist daher eine Eigenschaft des Paketpfads und keine Eigenschaft, die dem Benutzer folgt.

Path the request tookSource the site normally records
Client reaches the site at its tunnel address, 10.24.0.1Client inner address, 10.24.0.20
Client reaches another internet site through the gatewayGateway public egress address, 192.0.2.44
Client reaches the gateway's public address through the endpoint exceptionClient's own public access address

Genau diese dritte Zeile lohnt sich zuerst zu prüfen, wenn ein VPN-Benutzer im Log mit einer Adresse auftaucht, die nichts mit dem Tunnel zu tun hat. Sie erklärt auch, warum zwei Benutzer mit demselben Profil unterschiedliche Einträge erzeugen können: Ihre eigenen Zugangsnetze unterscheiden sich, und nichts im Tunnel überschreibt das.

Warum der äußere Endpunkt einen zweiten öffentlichen Pfad erzeugt

Der Client muss die öffentliche Adresse des Gateways erreichen, um den Tunnel aufzubauen, also muss eine Route zu dieser Adresse außerhalb des Tunnels existieren. Wenn ein Client den gesamten Verkehr nach innen umleitet, behält eine vernünftige Implementierung eine explizite Hostroute zur öffentlichen Adresse des Servers, um einen Tunnel zu vermeiden, der von sich selbst abhängt. Diese Ausnahme ist nicht dienstselektiv, also folgt ihr jede Anfrage an dieselbe öffentliche Adresse, einschließlich einer Browseranfrage an eine auf dem Gateway gehostete Site.

Das ist der Mechanismus hinter den meisten verwirrenden Berichten in diesem Bereich, und er liegt an der Clientimplementierung, nicht am Server. Zwei Clients mit identischen Profilen können sich daher unterschiedlich verhalten. Wer die Ausnahme entfernt, um das Log zu »reparieren«, reißt den Tunnel mit herunter, also behalten Sie sie und planen Sie um sie herum.

Socket, Tabelle und Logformat zusammen lesen

Drei Beobachtungen entscheiden, welchen Pfad Sie betrachten: wo der Socket lauscht, welche Schnittstelle das Ziel beantwortet und was das Logformat tatsächlich aufzeichnet. Ist der Listener nur an die Tunneladresse gebunden, kann eine öffentliche Anfrage ihn überhaupt nicht erreichen, was zwei Zeilen sofort ausschließt. Liefert die Suche für den Client das Tunnelgerät, kam die Anfrage mit einer inneren Quelle an, und das Log sollte das zeigen.

ss -lntp 'sport = :443'
ip route get 10.24.0.20
ip route get 192.0.2.44

Lesen Sie dann das Format statt der Zeile. Ein Feld, das aus einem weitergeleiteten Header gespeist wird, zeichnet eine Behauptung auf, keinen Socket-Peer, und die Behauptung zählt nur, wenn der unmittelbare Peer ein vertrauenswürdiger Proxy ist. Beide Werte ins Log zu schreiben, klärt spätere Diskussionen, weil der unmittelbare Peer und die ersetzte Adresse verschiedene Tatsachen sind und nur eine davon aus dem Netz kam.

log_format tunneled '$remote_addr $realip_remote_addr $request $status';
grep -n 'log_format' /etc/nginx/nginx.conf

Den gewünschten Einstiegspunkt wählen und DNS dazu bringen

Soll die Site nur über den Tunnel erreichbar sein, geben Sie ihr einen Namen, der für VPN-Clients auf die Tunneladresse auflöst, und erzwingen Sie die Richtlinie am lauschenden Socket. Eine Split-DNS-Antwort, die 10.24.0.1 für den internen Namen zurückgibt, ist eine Routingentscheidung im Kostüm eines Namensauflösungsdetails. Muss die Site auch öffentlich sein, behalten Sie zwei Namen oder zwei Ports und lassen Sie das Log sagen, welcher die Anfrage bedient hat.

Allow-Regeln folgen derselben Logik. Den Tunnel-Pool zuzulassen autorisiert keine öffentliche Anfrage und füllt keine innere Adresse auf einer Verbindung, die über das Internet kam. Beide Einstiegspunkte unter einem Namen zu mischen, macht die aufgezeichnete Quelle zu einem Nebeneffekt des Client-Routings statt zu einer Designentscheidung.

Erst den Pfad prüfen, dann die Richtlinie

Bestätigen Sie den Pfad mit einem Mitschnitt am Gateway und einer Anfrage, die Sie kontrollieren. Ein Mitschnitt am Tunnelgerät und einer an der öffentlichen Schnittstelle zeigen, welche die Bytes getragen hat, und die Reihenfolge der Pakete sagt Ihnen, ob dazwischen eine Übersetzung stattfand.

tcpdump -ni tun0 port 443 -c 5
tcpdump -ni eth0 port 443 -c 5

Prüfen Sie dann den Zugang in beide Richtungen: Der vorgesehene benannte Einstieg funktioniert für den vorgesehenen Client, und ein nicht freigegebener öffentlicher Pfad wird abgelehnt statt nur langsam zu sein. Eine allgemeine IP-Echo-Website beweist etwas über den Internetausgang des Gateways und nichts über diese Site auf demselben Host. Wenn eine Seite und ein WebSocket nicht übereinstimmen, vergleichen Sie ihre URLs, Adressfamilien und DNS-Antworten, bevor Sie die Serverkonfiguration anfassen.

Ähnliche Artikel