Client-Quellport gegenüber Server-Listener in einem VPN-Fluss
Vergleichen Sie die beiden Portnummern in einem Tunnel: den festen Listener des Servers und den kurzlebigen Quellport des Clients, und wie die Router-Übersetzung dazwischenliegt.
Zwei Nummern erscheinen in derselben Unterhaltung, und keine von beiden ist falsch. Das Serverprotokoll zeigt den Listener, der den Dienst anbietet, das Notebook zeigt den Socket, der das Datagramm gesendet hat, und ein Router dazwischen kann die zweite auf dem Weg nach draußen umschreiben. Die Enden der Unterhaltung zu vergleichen ist nützlicher, als die Ziffern zu vergleichen. Der Vergleich unten hält Listener, Client-Socket und übersetzte Quelle getrennt, weil sie unterschiedliche Fragen beantworten.
Zwei Nummern, die entgegengesetzte Enden beschreiben
Der konfigurierte Port des Servers ist das Ziel, das der Client anwählt. Er ist durch die Richtlinie festgelegt, erscheint im Profil und muss auf der Serverseite offen sein. Der Quellport des Clients wird lokal gewählt, meist aus dem ephemeren Bereich, und existiert, damit die Antwort irgendwo landen kann. Er kann sich bei jeder Wiederverbindung ändern, und nichts im Entwurf hängt davon ab, dass er stabil bleibt.
Ein Router dazwischen kann diese Quelle in sein eigenes 'NAT'-Mapping umschreiben. Deshalb hat die am Server beobachtete Nummer oft keinen Bezug zu der, die das Notebook gewählt hat.
Wo sich die Quellnummer unterwegs ändert
Nehmen Sie ein erfundenes IPv4-Beispiel: ein Client hinter einem übersetzenden Router, ein Server mit einem 'UDP'-Listener und ein einziges Datagramm, das beide durchläuft. Die Tabelle benennt jeden Endpunkt und was mit ihm geschieht, statt das Paket an drei Beobachtungspunkten nachzuspielen.
| Endpoint | What stays fixed | What changes on reconnect | Who owns it |
|---|---|---|---|
| Server listener | The service port and the address the profile names | Nothing; the listener does not follow the client | The server operator |
| Client socket | The destination it dials | The local source port, chosen per socket | The client, or its operating system |
| Translated source | Usually the public address of the router | The port, and sometimes the address after a network switch | The NAT device or the upstream carrier |
Das Ziel ist in jeder Zeile konstant, und nur die Identität der Quelle ändert sich. Anforderungen an UDP NAT unterscheiden eine interne Adresse und einen Port vom externen Mapping, was genau der Unterschied zwischen der zweiten und der dritten Zeile ist. Ein Router kann den Quellport des Clients beibehalten oder einen anderen wählen; Beibehaltung ist nichts, was eine Anwendung voraussetzen sollte.
Lesen Sie die drei Endpunkte auf den Hosts selbst
Die folgenden Auflistungen stammen von drei verschiedenen Rechnern und zeigen zusammen die ganze Unterhaltung. Führen Sie die erste auf dem Server, die zweite auf dem Client und die dritte dort aus, wo das Mapping existiert. Eine einzelne Protokollzeile zeigt nie alle drei.
ss -lunp 'sport = :1194'
ss -unp | grep 1194
conntrack -L -p udp | grep 1194Die erste Auflistung beweist, dass der Server an den Dienstport gebunden ist, und zeigt, welcher Prozess ihn besitzt. Die zweite zeigt den lokalen Socket des Clients und das Ziel, das er angewählt hat. Die dritte zeigt das vom Router erzeugte Mapping, und nur dort erscheint die übersetzte Quelle. Lesen Sie sie in dieser Reihenfolge, und die beiden Nummern wirken nicht mehr widersprüchlich.
Was eine Wiederverbindung ändert und was nicht
Manche Router behalten den Quellport des Clients, wenn er frei ist, andere vergeben jedes Mal einen anderen. Beide Verhaltensweisen sind normal, und eine Anwendung, die das erste verlangt, bricht beim zweiten. Eine Änderung des Mappings nach einer Wiederverbindung oder einem Netzwerkwechsel ist kein Serverfehler: Der Client öffnet einen neuen Socket, der Router vergibt, was er hat, und der Server sieht eine neue Quelle am selben Listener. Ein Fehler wäre es, zu erwarten, dass der Server Verkehr annimmt, der an einen beliebigen Client-Port adressiert ist.
Community-OpenVPN-Clients erhalten dieses Verhalten über nobind, wodurch das Betriebssystem den lokalen Port wählen darf; der entfernte Port kommt weiterhin aus dem Profil. Ausdrückliches Binden ist eine bewusste Entscheidung, keine Protokollanforderung. Der Server bietet weiter einen Endpunkt an, während Clients ihre eigenen lokalen Identitäten wählen.
Beschriften Sie die Schichten im Protokoll getrennt
Innerhalb des Tunnels gibt es eine zweite Unterhaltung mit eigenen Ports. Eine vom Tunnel getragene HTTPS-Anfrage hat das Ziel TCP 443, während die äußere verschlüsselte Verbindung UDP 1194 nutzt, sodass eine Änderung des äußeren Quellports am inneren Dienst nichts ändert.
Auch auf der äußeren Schicht zählt das Protokoll. UDP 1194 und TCP 1194 sind verschiedene Endpunkte, und ein 'TCP'-Listener wird nie ein UDP-Datagramm empfangen, nur weil die Nummer übereinstimmt. Wenn Sie eine Bereitstellung dokumentieren, beschriften Sie den Server-Listener, den Client-Socket und die übersetzte Quelle als drei verschiedene Dinge und ergänzen Sie bei jedem den Transport.
Dann folge die Richtlinie den Rollen. Der Server öffnet den vorgesehenen Transport an seinem Listener und authentifiziert weiterhin den Peer; die Firewall des Clients lässt Antworten auf seinen eigenen ausgehenden Austausch zu, ohne einen eingehenden Dienst zu veröffentlichen. Ein zustandsloser Filter braucht die Rückrichtung ausdrücklich, und das ist der praktische Grund, warum die Unterscheidung über saubere Diagramme hinaus zählt.