OpenVPN remote-random: geskommelde volgorde, een tonnel

Die aanname is dat die byvoeging van remote-random 'n profiel in 'n roterende poel verander, sodat elke verbinding uit 'n ander adres kom. Wat die richtlijn werklik doen, is om die lys remote-inskrywings een keer te skommel wanneer die kliënt begin verbind, en dit dan in daardie nuwe volgorde te probeer. Die tonnel wat uiteindelik opkom, eindig steeds by een eindpunt en bly daar vir die lewensduur van die sessie.

Daardie verskil maak saak vir beide toetsing en privaatheidsaansprake.

Wat die opsie by verbindingstyd verander

'n Kliëntprofiel kan verskeie remote-lyne bevat, elk met sy eie gasheernaam en poort. Sonder die richtlijn word hulle in lêervolgorde probeer; daarmee word die lys een keer by sessiebegin herrangskik en die eerste adres wat antwoord, wen. Die res bly terugvalopsies vir hierdie poging, nie parallelle paaie nie. 'n Profiel met 'n enkele remote gee die richtlijn niks om te skommel, wat die vinnigste manier is om te sien of dit saak kan maak.

OpenVPN se handleiding dokumenteer die opsie as iets wat die volgorde van verbindingspogings beïnvloed, wat presies die omvang is wat jy in die gedrag kan verwag.

'n Herverbinding begin 'n nuwe keusesiklus, so 'n latere sessie kan elders beland. Die lewende tonnel beweeg nie terwyl dit op is nie.

Mite: elke versoek kry 'n nuwe bediener

Sodra dit gevestig is, dra die tonnel alle verkeer vir daardie sessie na die gekose eweknie. Daar is geen herkeuse per versoek nie, en die richtlijn is nie 'n lasbalanseerder vir individuele verbindings nie: dit skommel kandidate, dit versprei nie pakkette nie. Elke toepassing wat daardie tonnel deel, deel dieselfde eweknie. Wat 'n blaaier ook al oor sy uitgang rapporteer, behoort aan die sessie, nie aan 'n individuele versoek nie.

As 'n toets twee verskillende uitgange wys, soek twee aparte sessies eerder as een slim opsie. Daardie onderskeid verduidelik ook waarom 'n blaaierstoets en 'n aflaaitoets kan verskil wanneer 'n herverbinding tussen hulle plaasgevind het.

Waarvoor remote-random-hostname is

'n Tweede richtlijn met 'n soortgelyke naam verander die gasheernaam wat vir oplossing gebruik word, nie die volgorde van die remote-lys nie. Dit bestaan vir ontplooiings waar 'n naam deur round-robin-DNS na verskeie adresse oplos, en dit moet net gebruik word wanneer die diens daarvoor gebou is. Net die oplossingsstap verander; die volgorde van die kandidaatlys nie.

Om dit te aktiveer omdat die name verwant lyk, is 'n algemene fout. 'n Wildcard-sertifikaat of 'n DNS-uitleg wat nie die gewysigde naam verwag nie, sal eenvoudig nie kan oplos of nie kan valideer nie.

Lees die gekose eindpunt uit die log

Teken aan watter eweknie 'n sessie werklik gebruik het voordat jy gevolgtrekkings maak. Uitgebreide uitvoer noem die adres wat geprobeer word, en die profiel self wys hoeveel kandidate daar is. Vergelyk daardie telling met die adres in die log voordat jy die skommeling blameer.

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

Vir 'n werkverrigtingvergeliking, pen die eindpunt vas deur die ander remotes uit te kommentaar, sodat die veranderlike wat getoets word die protokol of kliënt is eerder as die pad. Vir 'n privaatheidsvraag, evalueer die diens se identiteit en logboek as 'n geheel; 'n geskommelde eerste keuse wis nie koekies nie, verwyder nie 'n rekeningaanmelding nie en maak nie twee operateurs gelykwaardig nie.

Hou die meegeleverde vertrouensmateriaal en die ondersteunde eindpuntstel saam. Herverskikking verander net die volgorde waarin daardie stel geprobeer word.