OpenVPN remote-random: miksita ordo, unu tunelo

La supozo estas, ke aldono de remote-random transformas profilon en rotacian naĝejon, do ĉiu konekto eliras el malsama adreso. Kion la direktivo efektive faras: ĝi miksas la liston de remotoj unufoje, kiam la kliento komencas konektiĝi, kaj poste provas ilin laŭ tiu nova ordo. La tunelo, kiu fine ekfunkcias, ankoraŭ finiĝas ĉe unu finpunkto kaj restas tie dum la tuta vivo de la seanco.

Tiu diferenco gravas kaj por testado kaj por asertoj pri privateco.

Kion la opcio ŝanĝas ĉe konekta tempo

Klienta profilo povas enhavi plurajn liniojn remote, ĉiu kun propra hostnomo kaj pordo. Sen la direktivo ili proviĝas laŭ la dosiera ordo; kun ĝi, la listo permutiĝas unufoje ĉe la seanca komenco kaj venkas la unua adreso, kiu respondas. La ceteraj restas rezervoj por ĉi tiu provo, ne paralelaj vojoj. Profilo kun sola remote donas al la direktivo nenion miksindan, kaj tio estas la plej rapida maniero vidi, ĉu ĝi povas gravi.

La manlibro de OpenVPN dokumentas la opcion kiel influantan la ordon de konektprovoj, kaj ĝuste tiu amplekso atendindas en la konduto.

Rekonekto komencas novan elekton-ciklon, do posta seanco povas surteriĝi aliloke. La viva tunelo ne moviĝas dum ĝi funkcias.

Mito: ĉiu peto ricevas novan servilon

Post establado, la tunelo portas la tutan trafikon de tiu seanco al la elektita samtavolo. Ne estas reelekto por ĉiu peto, kaj la direktivo ne estas ŝarĝo-balancilo por individuaj konektoj: ĝi miksas kandidatojn, ĝi ne disigas pakojn. Ĉiu aplikaĵo, kiu dividas tiun tunelon, dividas la saman samtavolon. Kion ajn retumilo raportas pri sia eliro, apartenas al la seanco, ne al unuopa peto.

Se testo montras du malsamajn elirojn, serĉu du apartajn seancojn anstataŭ unu ruza opcion. Tiu distingo ankaŭ klarigas, kial retumila testo kaj elŝuta testo povas malkonsenti, kiam rekonekto okazis inter ili.

Por kio utilas remote-random-hostname

Dua direktivo kun simila nomo ŝanĝas la hostnomon uzatan por solvado, ne la ordon de la remote-listo. Ĝi ekzistas por aranĝoj, kie nomo solviĝas al pluraj adresoj per round-robin DNS, kaj ĝi uzu nur kiam la servo estas konstruita por tio. Nur la solva paŝo ŝanĝiĝas; la ordo de la kandidata listo ne.

Ŝalti ĝin ĉar la nomoj ŝajnas rilataj estas ofta eraro. Sovaĝkarta atestilo aŭ DNS-aranĝo, kiu ne atendas la ŝanĝitan nomon, simple malsukcesos solvi aŭ validigi.

Legu la elektitan finpunkton el la protokolo

Notu, kiun samtavolon seanco efektive uzis, antaŭ ol fari konkludojn. Detala eligo nomas la provatan adreson, kaj la profilo mem montras, kiom da kandidatoj ekzistas. Komparu tiun nombron kun la adreso en la protokolo, antaŭ ol kulpigi la miksadon.

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

Por agorda komparo, fiksu la finpunkton komentante la aliajn remotojn, por ke la testata variablo estu la protokolo aŭ la kliento, ne la vojo. Por privateca demando, taksu la identecon de la servo kaj ĝian protokoladon kiel tuton; miksita unua elekto ne forigas kuketojn, ne forigas kontan ensaluton kaj ne igas du operatorojn ekvivalentaj.

Tenu kune la liveritan fidaĵaron kaj la subtenatan finpunktan aron. Remiksado ŝanĝas nur la ordon, laŭ kiu tiu aro proviĝas.