Warum sich viele App-Verbindungen eine OpenVPN-Sitzung teilen

Stellen Sie sich einen Browser vor, der eine HTTPS-Seite lädt, während ein SSH-Client einen anderen Server erreicht und ein Resolver eine Anfrage beantwortet, alles über eine OpenVPN-Sitzung. Auf der physischen Schnittstelle sehen Sie ein Gespräch; im Tunnel sehen Sie drei. Beide Sichten sind richtig, und zu wissen warum ist der Unterschied zwischen einer brauchbaren Aufzeichnung und einer verwirrenden. Folgen Sie einem inneren Fluss vom Socket bis zum Draht, und die Schichtung hört auf, abstrakt zu sein.

Ein äußeres Gespräch, viele innere Flüsse

Jede Anwendung öffnet ihren eigenen Socket, und der Kernel gibt ihr ein Fünftupel aus Quelladresse, Quellport, Zieladresse, Zielport und Protokoll. Diese Tupel existieren, bevor irgendein Tunnel im Spiel ist. Dann entscheidet das Routing, dass alle über das Tunnelgerät hinausgehen, sodass das an OpenVPN übergebene Paket die ursprünglichen Header noch in sich trägt. OpenVPN verschlüsselt dieses innere Paket und verpackt das Ergebnis in ein einziges äußeres UDP- oder TCP-Gespräch mit dem Peer. Das äußere Gespräch ist also eines, während die Flüsse darin so zahlreich sind, wie die Anwendungen sie geöffnet haben.

Nichts fällt zusammen. Die inneren Tupel überleben von Ende zu Ende, und deshalb kann die Gegenseite die drei Flüsse noch auseinanderhalten.

Der Port, der fest bleibt

Konstant bleibt das äußere Tupel: Ihre Adresse, der lokale Port, den der Client gebunden hat, die Peer-Adresse und der konfigurierte Dienstport. Genau dieses Tupel muss eine Firewall oder ein NAT auf dem Weg zulassen, und genau dieses zeigt eine Aufzeichnung am Uplink. Es ist auch das, was sich nach einem Reconnect oder einem Netzwerkwechsel ändert, weil der Client einen anderen lokalen Port binden kann. Ein Tunnel bedeutet nicht ewig einen festen Quellport.

Die inneren Ports sind das, worauf es für die Endpunkte ankommt. Ein HTTPS-Fluss behält Zielport 443 im Tunnel, obwohl der äußere Transport auf dem Port sitzt, den der Betreiber konfiguriert hat. Die Anwendungsendpunkte erfahren von dem äußeren nie etwas.

Was die Entkapselung am fernen Ende ändert

Beim Peer wird die äußere Schicht abgenommen, und das innere Paket bleibt übrig. Von dort gelten Weiterleitung und Zugriffsrichtlinie für das innere Ziel und Protokoll. Der Webserver erhält weiterhin eine HTTPS-Verbindung, der SSH-Daemon erhält weiterhin SSH, und der Resolver erhält weiterhin eine Anfrage.

Deshalb ist eine Regel, die den äußeren Transport erlaubt, nicht dieselbe Regel wie die Erlaubnis eines internen Dienstes. Die erste beschreibt einen Pfad; die zweite beschreibt eine Autorisierung.

TCP außen bedeutet ein Strom, nicht eine Verbindung

Ist der äußere Transport UDP, ist das Schicksal jedes inneren Flusses unabhängig: ein verlorenes Datagramm betrifft eine Übertragung bis zu deren eigener Wiederholung. Ist der äußere Transport TCP, teilen alle inneren Flüsse einen zuverlässigen Bytestrom.

Dieser gemeinsame Strom ist der Teil, den Leute übersehen. Wiederherstellung geschieht einmal, für alles, sodass ein einziges verlorenes Segment den Verkehr jeder darin gemultiplexten Anwendung verzögert. Es sind weiterhin viele Verbindungen an den Endpunkten und eine Verbindung auf dem Draht, und auf dem Draht lebt der Head-of-Line-Effekt. Die Zahl der lauschenden Ports sagt Ihnen darüber nichts, weshalb Ports zu zählen ein schlechter Weg ist, über Tunnel-Leistung nachzudenken.

Beschreiben Sie Ihr eigenes Setup genau

Benennen Sie den ausgewählten inneren Verkehr und den konkreten äußeren Transport, der ihn trägt, statt zu sagen, die Maschine schicke alles über einen Port. Lokale Dienste, ein zweiter Tunnel und die andere Adressfamilie erzeugen alle Flüsse, die nie in dieses Gespräch eintreten. Eine Aufzeichnung am Uplink zeigt das äußere Tupel; eine Aufzeichnung im Tunnel zeigt die inneren.

Nehmen Sie beide und legen Sie die Zeitstempel nebeneinander. Wenn Sie belegen müssen, welche Anwendung welchen inneren Fluss erzeugt hat, ist die Socket-Tabelle auf dem Host das bessere Instrument, weil sie Ports direkt Prozessen zuordnet. Notieren Sie dann das beobachtete äußere Tupel und den Moment der Beobachtung, denn die nächste Aufzeichnung nach einem Reconnect kann legitim andere Zahlen zeigen.