OpenVPN remote-random: door elkaar geschudde volgorde, één tunnel

De aanname is dat het toevoegen van remote-random een profiel in een roterende pool verandert, zodat elke verbinding van een ander adres komt. Wat de richtlijn werkelijk doet, is de lijst met remotes één keer door elkaar schudden wanneer de client begint te verbinden, en ze daarna in die nieuwe volgorde proberen. De tunnel die uiteindelijk opkomt, eindigt nog steeds op één eindpunt en blijft daar voor de hele levensduur van de sessie.

Dat verschil is belangrijk voor zowel tests als privacyclaims.

Wat de optie verandert bij het verbinden

Een clientprofiel kan meerdere remote-regels bevatten, elk met een eigen hostnaam en poort. Zonder de richtlijn worden ze in bestandsvolgorde geprobeerd; met de richtlijn wordt de lijst één keer bij de start van de sessie door elkaar geschud en wint het eerste adres dat antwoordt. De rest blijft reserve voor deze poging, geen parallelle paden. Een profiel met één remote geeft de richtlijn niets om te schudden, en dat is de snelste manier om te zien of het iets kan uitmaken.

De handleiding van OpenVPN documenteert de optie als van invloed op de volgorde van verbindingspogingen, en dat is precies de reikwijdte die je in het gedrag kunt verwachten.

Opnieuw verbinden start een nieuwe selectiecyclus, dus een latere sessie kan ergens anders terechtkomen. De actieve tunnel verplaatst niet zolang hij overeind staat.

Mythe: elk verzoek krijgt een nieuwe server

Zodra de tunnel staat, draagt hij al het verkeer van die sessie naar de gekozen peer. Er is geen herselectie per verzoek, en de richtlijn is geen load balancer voor afzonderlijke verbindingen: hij schudt kandidaten door elkaar, hij verdeelt geen pakketten. Elke toepassing die die tunnel deelt, deelt dezelfde peer. Wat een browser ook meldt over zijn uitgang, het hoort bij de sessie, niet bij een afzonderlijk verzoek.

Als een test twee verschillende uitgangen laat zien, zoek dan twee afzonderlijke sessies in plaats van één slimme optie. Dat onderscheid verklaart ook waarom een browsertest en een downloadtest kunnen verschillen wanneer er tussen beide een herverbinding plaatsvond.

Waar remote-random-hostname voor is

Een tweede richtlijn met een vergelijkbare naam verandert de hostnaam die voor resolutie wordt gebruikt, niet de volgorde van de remote-lijst. Hij bestaat voor implementaties waarin een naam via round-robin DNS naar meerdere adressen wordt herleid, en hij mag alleen worden gebruikt wanneer de dienst daarvoor is gebouwd. Alleen de resolutiestap verandert; de volgorde van de kandidatenlijst niet.

Hem inschakelen omdat de namen verwant lijken, is een veelgemaakte fout. Een wildcardcertificaat of een DNS-indeling die de gewijzigde naam niet verwacht, zal eenvoudigweg niet kunnen herleiden of valideren.

Lees het gekozen eindpunt uit de log

Noteer welke peer een sessie werkelijk heeft gebruikt voordat je conclusies trekt. Uitgebreide uitvoer noemt het adres dat wordt geprobeerd, en het profiel zelf toont hoeveel kandidaten er zijn. Vergelijk dat aantal met het adres in de log voordat je het schudden de schuld geeft.

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

Voor een prestatievergelijking zet je het eindpunt vast door de andere remotes uit te commentariëren, zodat de variabele die wordt getest het protocol of de client is en niet het pad. Voor een privacyvraag beoordeel je de identiteit van de dienst en de logging als geheel; een door elkaar geschudde eerste keuze wist geen cookies, verwijdert geen accountlogin en maakt twee operators niet gelijkwaardig.

Houd het meegeleverde vertrouwensmateriaal en de ondersteunde set eindpunten bij elkaar. Opnieuw schudden verandert alleen de volgorde waarin die set wordt geprobeerd.