OpenVPN remote-random: blandad ordning, en tunnel

Antagandet är att tillägget av remote-random förvandlar en profil till en roterande pool, så att varje anslutning kommer ut från en annan adress. Vad direktivet faktiskt gör är att blanda listan över remote-poster en gång, när klienten börjar ansluta, och sedan prova dem i den nya ordningen. Tunneln som till slut kommer upp slutar fortfarande på en enda slutpunkt och stannar där under hela sessionens livstid.

Den skillnaden spelar roll både för tester och för påståenden om integritet.

Vad alternativet ändrar vid anslutning

En klientprofil kan innehålla flera remote-rader, var och en med eget värdnamn och port. Utan direktivet provas de i filordning; med det permuteras listan en gång vid sessionsstart och den första adress som svarar vinner. Resten blir reserv för detta försök, inte parallella vägar. En profil med bara en remote ger direktivet inget att blanda, och det är det snabbaste sättet att se om det kan spela någon roll.

OpenVPN-handboken dokumenterar alternativet som att det påverkar ordningen för anslutningsförsök, och det är exakt det omfång man bör förvänta sig i beteendet.

En återanslutning startar en ny urvalscykel, så en senare session kan hamna någon annanstans. Den aktiva tunneln flyttar sig inte medan den är uppe.

Myt: varje begäran får en ny server

När tunneln är upprättad bär den all trafik för den sessionen till den valda peeren. Det finns inget nytt val per begäran, och direktivet är inte en lastbalanserare för enskilda anslutningar: det blandar kandidater, det fördelar inte paket. Varje program som delar den tunneln delar samma peer. Vad en webbläsare än rapporterar om sin utgång tillhör sessionen, inte en enskild begäran.

Om ett test visar två olika utgångar, leta efter två separata sessioner i stället för ett smart alternativ. Den skillnaden förklarar också varför ett webbläsartest och ett nedladdningstest kan vara oense när en återanslutning skedde mellan dem.

Vad remote-random-hostname är till för

Ett andra direktiv med liknande namn ändrar värdnamnet som används för uppslagning, inte ordningen i remote-listan. Det finns för driftsättningar där ett namn löses upp till flera adresser via round-robin DNS, och det bör bara användas när tjänsten är byggd för det. Bara uppslagningssteget ändras; ordningen i kandidatlistan gör det inte.

Att aktivera det för att namnen ser besläktade ut är ett vanligt misstag. Ett wildcard-certifikat eller en DNS-layout som inte förväntar sig det ändrade namnet kommer helt enkelt inte att kunna lösa upp eller validera.

Läs den valda slutpunkten i loggen

Notera vilken peer en session faktiskt använde innan du drar slutsatser. Utförliga utdata namnger adressen som provas, och själva profilen visar hur många kandidater som finns. Jämför det antalet med adressen i loggen innan du skyller på blandningen.

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 en prestandajämförelse fäster du slutpunkten genom att kommentera bort de andra remote-posterna, så att variabeln som testas är protokollet eller klienten och inte vägen. För en integritetsfråga utvärderar du tjänstens identitet och loggning som helhet; ett blandat förstahandsval rensar inte cookies, tar inte bort en kontoinloggning och gör inte två operatörer likvärdiga.

Håll det medföljande förtroendematerialet och den stödda uppsättningen slutpunkter tillsammans. Ny blandning ändrar bara ordningen som den uppsättningen provas i.