OpenVPN remote-random: blanda rekkjefølgje, éin tunnel

Føresetnaden er at det å leggje til remote-random gjer ein profil om til ein roterande pool, slik at kvar tilkopling kjem ut frå ei anna adresse. Det direktivet faktisk gjer, er å blande lista over remote-oppføringar éin gong, når klienten byrjar å kople til, og deretter prøve dei i den nye rekkjefølgja. Tunnelen som til slutt kjem opp, endar framleis på eitt endepunkt og blir der i heile levetida til sesjonen.

Den skilnaden har noko å seie både for testing og for personvernpåstandar.

Kva alternativet endrar ved tilkopling

Ein klientprofil kan innehalde fleire remote-linjer, kvar med eige vertsnamn og port. Utan direktivet blir dei prøvde i filrekkjefølgje; med det blir lista permutert éin gong ved sesjonsstart, og den første adressa som svarar vinn. Resten blir verande reserveval for dette forsøket, ikkje parallelle vegar. Ein profil med berre éin remote gir direktivet ingenting å blande, og det er den raskaste måten å sjå om det kan ha noko å seie.

OpenVPN-handboka dokumenterer alternativet som noko som påverkar rekkjefølgja av tilkoplingsforsøk, og det er nøyaktig det omfanget ein bør vente i åtferda.

Ei ny tilkopling startar ein ny utvalssyklus, så ein seinare sesjon kan hamne ein annan stad. Den aktive tunnelen flyttar seg ikkje medan han er oppe.

Myte: kvar førespurnad får ein ny server

Når tunnelen er etablert, ber han all trafikk for den sesjonen til den valde peeren. Det er inga ny utveljing per førespurnad, og direktivet er ikkje ein lastbalansar for individuelle tilkoplingar: det blandar kandidatar, det fordeler ikkje pakkar. Kvar applikasjon som deler den tunnelen, deler den same peeren. Uansett kva ein nettlesar rapporterer om utgangen sin, høyrer det til sesjonen, ikkje til ein enkelt førespurnad.

Viss ein test viser to ulike utgangar, leit etter to separate sesjonar i staden for eitt smart alternativ. Den skilnaden forklarer òg kvifor ein nettlesartest og ein nedlastingstest kan vere usamde når ei ny tilkopling skjedde mellom dei.

Kva remote-random-hostname er for

Eit andre direktiv med eit liknande namn endrar vertsnamnet som blir brukt til oppslag, ikkje rekkjefølgja i remote-lista. Det finst for utrullingar der eit namn blir løyst opp til fleire adresser via round-robin DNS, og det bør berre brukast når tenesta er bygd for det. Berre oppslagstrinnet blir endra; rekkjefølgja i kandidatlista blir ikkje det.

Å slå det på fordi namna ser skylde ut, er ein vanleg feil. Eit wildcard-sertifikat eller eit DNS-oppsett som ikkje ventar det endra namnet, vil rett og slett ikkje kunne løyse opp eller validere.

Les det valde endepunktet frå loggen

Noter kva peer ein sesjon faktisk brukte før du dreg konklusjonar. Detaljert utdata namngir adressa som blir prøvd, og sjølve profilen viser kor mange kandidatar som finst. Samanlikn det talet med adressa i loggen før du gir blandinga skulda.

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 ein ytingssamanlikning fest du endepunktet ved å kommentere ut dei andre remote-oppføringane, slik at variabelen som blir testa er protokollen eller klienten og ikkje vegen. For eit personvernspørsmål vurderer du identiteten til tenesta og logginga som heilskap; eit blanda førsteval slettar ikkje informasjonskapslar, fjernar ikkje ei kontopålogging og gjer ikkje to operatørar likeverdige.

Hald det medfølgjande tillitsmaterialet og det støtta settet med endepunkt saman. Ny blanding endrar berre rekkjefølgja det settet blir prøvd i.