OpenVPN remote-random: blandet rekkefølge, én tunnel

Antakelsen er at det å legge til remote-random gjør en profil om til en roterende pool, slik at hver tilkobling kommer ut fra en annen adresse. Det direktivet faktisk gjør, er å blande listen over remote-oppføringer én gang, når klienten begynner å koble til, og deretter prøve dem i den nye rekkefølgen. Tunnelen som til slutt kommer opp, ender fortsatt på ett endepunkt og blir der i hele sesjonens levetid.

Den forskjellen betyr noe både for testing og for personvernpåstander.

Hva alternativet endrer ved tilkobling

En klientprofil kan inneholde flere remote-linjer, hver med eget vertsnavn og port. Uten direktivet prøves de i filrekkefølge; med det permuteres listen én gang ved sesjonsstart, og den første adressen som svarer vinner. Resten forblir reservevalg for dette forsøket, ikke parallelle veier. En profil med bare én remote gir direktivet ingenting å blande, og det er den raskeste måten å se om det kan ha noe å si.

OpenVPN-håndboken dokumenterer alternativet som å påvirke rekkefølgen av tilkoblingsforsøk, og det er nøyaktig det omfanget man bør forvente i oppførselen.

En ny tilkobling starter en ny utvelgelsessyklus, så en senere sesjon kan havne et annet sted. Den aktive tunnelen flytter seg ikke mens den er oppe.

Myte: hver forespørsel får en ny server

Når tunnelen er etablert, bærer den all trafikk for den sesjonen til den valgte peeren. Det er ingen ny utvelgelse per forespørsel, og direktivet er ikke en lastbalanserer for individuelle tilkoblinger: det blander kandidater, det fordeler ikke pakker. Hver applikasjon som deler den tunnelen, deler den samme peeren. Uansett hva en nettleser rapporterer om utgangen sin, tilhører det sesjonen, ikke en enkelt forespørsel.

Hvis en test viser to forskjellige utganger, se etter to separate sesjoner i stedet for ett smart alternativ. Den forskjellen forklarer også hvorfor en nettlesertest og en nedlastingstest kan være uenige når en ny tilkobling skjedde mellom dem.

Hva remote-random-hostname er for

Et andre direktiv med et lignende navn endrer vertsnavnet som brukes til oppslag, ikke rekkefølgen i remote-listen. Det finnes for utrullinger der et navn løses opp til flere adresser via round-robin DNS, og det bør bare brukes når tjenesten er bygget for det. Bare oppslagstrinnet endres; rekkefølgen i kandidatlisten gjør det ikke.

Å aktivere det fordi navnene ser beslektet ut, er en vanlig feil. Et wildcard-sertifikat eller et DNS-oppsett som ikke forventer det endrede navnet, vil rett og slett ikke kunne løse opp eller validere.

Les det valgte endepunktet fra loggen

Noter hvilken peer en sesjon faktisk brukte før du trekker konklusjoner. Detaljert utdata navngir adressen som prøves, og selve profilen viser hvor mange kandidater som finnes. Sammenlign det tallet med adressen i loggen før du gir blandingen skylden.

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

For en ytelsessammenligning fester du endepunktet ved å kommentere ut de andre remote-oppføringene, slik at variabelen som testes er protokollen eller klienten og ikke veien. For et personvernspørsmål vurderer du tjenestens identitet og logging som helhet; et blandet førstvalg sletter ikke informasjonskapsler, fjerner ikke en kontopålogging og gjør ikke to operatører likeverdige.

Hold det medfølgende tillitsmaterialet og det støttede settet med endepunkter sammen. Ny blanding endrer bare rekkefølgen det settet prøves i.