OpenVPN remote-random: gemischte Reihenfolge, ein Tunnel

Die Annahme ist, dass das Hinzufügen von remote-random ein Profil in einen rotierenden Pool verwandelt, sodass jede Verbindung von einer anderen Adresse ausgeht. Was die Direktive tatsächlich tut, ist die Liste der Remotes einmal zu mischen, wenn der Client die Verbindung aufbaut, und sie dann in dieser neuen Reihenfolge zu versuchen. Der Tunnel, der schließlich zustande kommt, endet weiterhin an einem einzigen Endpunkt und bleibt dort für die Lebensdauer der Sitzung.

Dieser Unterschied ist sowohl für Tests als auch für Datenschutzbehauptungen wichtig.

Was die Option beim Verbindungsaufbau ändert

Ein Clientprofil kann mehrere remote-Zeilen enthalten, jede mit eigenem Hostnamen und Port. Ohne die Direktive werden sie in Dateireihenfolge versucht; mit ihr wird die Liste beim Sitzungsstart einmal permutiert, und die erste Adresse, die antwortet, gewinnt. Die übrigen bleiben Ausweichmöglichkeiten für diesen Versuch, keine parallelen Pfade. Ein Profil mit nur einem Remote gibt der Direktive nichts zu mischen, und das ist der schnellste Weg zu sehen, ob sie überhaupt von Bedeutung sein kann.

Das OpenVPN-Handbuch dokumentiert die Option als Einfluss auf die Reihenfolge der Verbindungsversuche, und genau das ist der Umfang, den man im Verhalten erwarten sollte.

Eine Wiederverbindung beginnt einen neuen Auswahlzyklus, sodass eine spätere Sitzung woanders landen kann. Der laufende Tunnel bewegt sich nicht, solange er steht.

Mythos: Jede Anfrage bekommt einen neuen Server

Sobald der Tunnel steht, trägt er den gesamten Verkehr dieser Sitzung zu dem gewählten Peer. Es gibt keine Neuauswahl pro Anfrage, und die Direktive ist kein Lastverteiler für einzelne Verbindungen: Sie mischt Kandidaten, sie verteilt keine Pakete. Jede Anwendung, die diesen Tunnel teilt, teilt denselben Peer. Was auch immer ein Browser über seinen Ausgang meldet, gehört zur Sitzung, nicht zu einer einzelnen Anfrage.

Wenn ein Test zwei verschiedene Ausgänge zeigt, suche zwei getrennte Sitzungen statt einer cleveren Option. Dieser Unterschied erklärt auch, warum ein Browsertest und ein Downloadtest voneinander abweichen können, wenn dazwischen eine Wiederverbindung stattfand.

Wofür remote-random-hostname gedacht ist

Eine zweite Direktive mit ähnlichem Namen ändert den für die Auflösung verwendeten Hostnamen, nicht die Reihenfolge der Remote-Liste. Sie existiert für Umgebungen, in denen ein Name über Round-Robin-DNS in mehrere Adressen aufgelöst wird, und sollte nur verwendet werden, wenn der Dienst dafür gebaut ist. Nur der Auflösungsschritt ändert sich; die Reihenfolge der Kandidatenliste nicht.

Sie zu aktivieren, weil die Namen verwandt klingen, ist ein häufiger Fehler. Ein Wildcard-Zertifikat oder ein DNS-Layout, das den veränderten Namen nicht erwartet, schlägt schlicht bei der Auflösung oder bei der Validierung fehl.

Den ausgewählten Endpunkt aus dem Log ablesen

Halte fest, welchen Peer eine Sitzung tatsächlich genutzt hat, bevor du Schlüsse ziehst. Ausführliche Ausgaben nennen die versuchte Adresse, und das Profil selbst zeigt, wie viele Kandidaten es gibt. Vergleiche diese Zahl mit der Adresse im Log, bevor du das Mischen verantwortlich machst.

grep -c '^remote ' client.ovpn
openvpn --config client.ovpn --verb 4 2>&1 | grep -i -E 'attempting|peer connection'
openvpn --help | grep -A2 remote-random
head -20 client.ovpn

Für einen Leistungsvergleich fixiere den Endpunkt, indem du die anderen Remotes auskommentierst, damit die getestete Variable das Protokoll oder der Client ist und nicht der Pfad. Für eine Datenschutzfrage bewerte die Identität des Dienstes und seine Protokollierung als Ganzes; eine gemischte erste Wahl löscht keine Cookies, entfernt keinen Kontologin und macht zwei Betreiber nicht gleichwertig.

Halte das mitgelieferte Vertrauensmaterial und die unterstützte Endpunktmenge zusammen. Das erneute Mischen ändert nur die Reihenfolge, in der diese Menge versucht wird.