OpenVPN remote-random: összekevert sorrend, egyetlen alagút

A feltevés az, hogy a remote-random hozzáadása a profilt forgó gyűjteménnyé teszi, így minden kapcsolat más címről jön ki. Amit az utasítás valójában tesz: egyszer összekeveri a remote-ok listáját, amikor a kliens elkezd kapcsolódni, majd ebben az új sorrendben próbálja ki őket. A végül felálló alagút továbbra is egyetlen végpontnál végződik, és ott is marad a munkamenet teljes élettartama alatt.

Ez a különbség számít a tesztelésnél és az adatvédelmi állításoknál is.

Mit változtat a beállítás kapcsolódáskor

Egy kliensprofil több remote sort is tartalmazhat, mindegyiket saját gazdagépnevével és portjával. Az utasítás nélkül fájlsorrendben próbálják ki őket; vele a lista a munkamenet elején egyszer permutálódik, és az első válaszoló cím nyer. A többi ehhez a kísérlethez tartalék marad, nem párhuzamos útvonal. Az egyetlen remote-ot tartalmazó profil semmit sem ad az utasításnak keverni, és ez a leggyorsabb módja annak megállapítására, hogy egyáltalán számíthat-e.

Az OpenVPN kézikönyve úgy dokumentálja a beállítást, mint ami a kapcsolódási kísérletek sorrendjét befolyásolja, és pontosan ez az a hatókör, amely a viselkedésben várható.

Az újracsatlakozás új kiválasztási ciklust indít, így egy későbbi munkamenet máshol köthet ki. Az élő alagút nem mozdul, amíg áll.

Tévhit: minden kérés új szervert kap

Miután létrejött, az alagút a munkamenet teljes forgalmát a kiválasztott partnerhez viszi. Nincs kérésenkénti újraválasztás, és az utasítás nem terheléselosztó az egyes kapcsolatokhoz: jelölteket kever, nem oszt szét csomagokat. Minden alkalmazás, amely ezt az alagutat megosztja, ugyanazt a partnert osztja meg. Amit egy böngésző a kimenetéről jelent, a munkamenethez tartozik, nem egyetlen kéréshez.

Ha egy teszt két különböző kimenetet mutat, keress két külön munkamenetet egyetlen ravasz beállítás helyett. Ez a különbség azt is megmagyarázza, miért térhet el egymástól egy böngészős teszt és egy letöltési teszt, ha közöttük újracsatlakozás történt.

Mire való a remote-random-hostname

Egy második, hasonló nevű utasítás a feloldáshoz használt gazdagépnevet változtatja meg, nem a remote-lista sorrendjét. Olyan telepítésekhez létezik, ahol egy név round-robin DNS-en keresztül több címre oldódik fel, és csak akkor szabad használni, ha a szolgáltatás erre épült. Csak a feloldási lépés változik; a jelöltlista sorrendje nem.

Bekapcsolni azért, mert a nevek rokonnak tűnnek, gyakori hiba. Egy wildcard tanúsítvány vagy egy olyan DNS-elrendezés, amely nem számít a módosított névre, egyszerűen nem fog feloldódni vagy érvényesülni.

Olvasd ki a kiválasztott végpontot a naplóból

Jegyezd fel, melyik partnert használta a munkamenet valójában, mielőtt következtetéseket vonsz le. A részletes kimenet megnevezi a próbált címet, és maga a profil mutatja, hány jelölt van. Hasonlítsd össze ezt a számot a naplóban szereplő címmel, mielőtt a keverést okolnád.

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

Teljesítmény-összehasonlításhoz rögzítsd a végpontot a többi remote kikommentelésével, hogy a vizsgált változó a protokoll vagy a kliens legyen, ne az útvonal. Adatvédelmi kérdéshez a szolgáltatás identitását és naplózását egészében értékeld; az összekevert első választás nem törli a sütiket, nem távolítja el a fiókba való bejelentkezést, és nem tesz két szolgáltatót egyenértékűvé.

Tartsd együtt a szállított bizalmi anyagot és a támogatott végponthalmazt. Az újrakeverés csak azt a sorrendet változtatja meg, ahogyan ezt a halmazt kipróbálják.