OpenVPN remote-random: blandet rækkefølge, én tunnel

Antagelsen er, at tilføjelse af remote-random gør en profil til en roterende pulje, så hver forbindelse kommer ud fra en anden adresse. Hvad direktivet faktisk gør, er at blande listen af remotes én gang, når klienten begynder at forbinde, og derefter prøve dem i den nye rækkefølge. Den tunnel, der til sidst kommer op, ender stadig på ét endpoint og bliver der i hele sessionens levetid.

Den forskel betyder noget for både test og privatlivspåstande.

Hvad indstillingen ændrer ved forbindelsestidspunktet

En klientprofil kan indeholde flere remote-linjer, hver med sit eget værtsnavn og sin egen port. Uden direktivet prøves de i filrækkefølge; med det permuteres listen én gang ved sessionens start, og den første adresse, der svarer, vinder. Resten forbliver fallback for dette forsøg, ikke parallelle veje. En profil med et enkelt remote giver direktivet intet at blande, og det er den hurtigste måde at se, om det kan betyde noget.

OpenVPN's manual dokumenterer indstillingen som havende indflydelse på rækkefølgen af forbindelsesforsøg, og det er præcis det omfang, man skal forvente i adfærden.

En genopkobling starter en ny valgcyklus, så en senere session kan ende et andet sted. Den live tunnel flytter sig ikke, mens den er oppe.

Myte: hver anmodning får en ny server

Når tunnelen er etableret, bærer den al trafik for den session til den valgte peer. Der er ingen genvalg for hver anmodning, og direktivet er ikke en load balancer for individuelle forbindelser: det blander kandidater, det fordeler ikke pakker. Hver applikation, der deler den tunnel, deler den samme peer. Uanset hvad en browser rapporterer om sin udgang, tilhører det sessionen, ikke en enkelt anmodning.

Hvis en test viser to forskellige udgange, så led efter to separate sessioner i stedet for én smart indstilling. Den forskel forklarer også, hvorfor en browsertest og en downloadtest kan være uenige, når der er sket en genopkobling mellem dem.

Hvad remote-random-hostname er til

Et andet direktiv med et lignende navn ændrer det værtsnavn, der bruges til opløsning, ikke rækkefølgen af remote-listen. Det findes til installationer, hvor et navn opløses til flere adresser via round-robin DNS, og det bør kun bruges, når tjenesten er bygget til det. Kun opløsningstrinnet ændres; rækkefølgen af kandidatlisten gør ikke.

At aktivere det, fordi navnene ser beslægtede ud, er en almindelig fejl. Et wildcard-certifikat eller et DNS-opsætning, der ikke forventer det ændrede navn, vil ganske enkelt ikke kunne opløse eller validere.

Læs det valgte endpoint fra loggen

Notér, hvilken peer en session faktisk brugte, før du drager konklusioner. Verbose-output angiver den adresse, der forsøges, og selve profilen viser, hvor mange kandidater der findes. Sammenlign det antal med adressen i loggen, før du bebrejder blandingen.

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

Til en ydeevnesammenligning fastgør du endpointet ved at kommentere de andre remotes ud, så variablen under test er protokollen eller klienten frem for vejen. Til et privatlivsspørgsmål skal du vurdere tjenestens identitet og logning som helhed; et blandet førstevalg sletter ikke cookies, fjerner ikke et kontologin og gør ikke to operatører ens.

Hold det medfølgende tillidsmateriale og det understøttede sæt endpoints sammen. Omblending ændrer kun den rækkefølge, hvori sættet prøves.