Peer-adressa vart endra midt i økta: kva OpenVPN float gjer

Den berbare maskina flyttar frå Wi-Fi på kontoret til eit hotspot på telefonen, tunnelen held seg eit par sekund til, og så stoggar trafikken medan grensesnittet framleis hevdar at det er tilkopla. På tenaren viser statuslista framleis den gamle offentlege adressa. Dette er situasjonen float finst for, og det er òg situasjonen der folk ventar langt meir av det enn det gjer. Å få grensa rett gjer ein forvirrande stopp til anten ei konfigurasjonsendring på éi linje eller ei heilt anna undersøking.

Kva float lempar på, og kva det aldri lempar på

Vanlegvis held ei økt fram med å snakke med den ytre adressa og porten ho starta med, og pakkar som kjem frå andre stader vert ignorerte. Alternativet float fjernar den strenge bindinga når peeren fyrst har prova seg, slik at ei endra kjeldeadresse-mapping kan halde fram i same økta i staden for å verte kasta. Ingenting ved dei kryptografiske kontrollane vert endra: nøklar, sertifikat og kvar som helst HMAC-vern held seg nøyaktig som konfigurert.

Dette er ei avgjerd per pakke, ikkje ein policy om kven som får kople til. Ei ukjend maskin som sender ein pakke frå ei ny adresse har ikkje prova noko, og pakken vert kasta som all annan uautentisert trafikk. Berre trafikk som går gjennom økta si eiga autentisering kan flytte den registrerte peer-adressa, og difor er det trygt å la float stå på i miljø der klientane roamar.

Det seier heller ingenting om den indre tunnelen. Ei flytta ytre adresse tildeler ikkje ei tunneladresse på nytt, endrar ikkje bassenget og gir ikkje peeren tilgang til noko nytt. Inne i tunnelen gjeld same identitet og same dytta ruter før og etter flyttinga. Ein roam forhandlar heller ikkje datakanalen på nytt, så den forhandla chifferen og nøklane held fram.

Pakken som flyttar ei økt, må autentiserast

Start ei økt på vanleg måte mot den konfigurerte eksterne enden, og float handterer det som skjer når mappinga vert endra. Ein mobiloperatør som omnummererer midt i straumen, ein NAT-gateway som skriv om portmappinga si, eller ein berbar maskin som byter uplink gir alle same form: autentiserte pakkar frå ein ny tuple, som kjem til ei økt som framleis trur på den gamle.

Når du vert spurd om float verkar, er det nyttige beviset eit fullført handtrykk etterfølgt av ei godteken kjeldeendring, ikkje ei logglinje om adressa åleine. Korreler den gamle og den nye ytre adressa med økta som heldt seg i live, og stadfest deretter at trafikken faktisk heldt fram gjennom tunnelen.

Døyr økta i staden for å flytte seg, mislukkast pakken frå den nye adressa truleg i autentisering eller kom ikkje fram i det heile. Begge tilfella ser like ut frå klienten. På tenaren fortel ein fangst på det offentlege grensesnittet deg kva du har før du rører nokon konfigurasjon.

Oppdaging er ein heilt separat mekanisme

float løyser ikkje namn på ein timer og sporar ikkje ein dynamisk DNS-post. Viss vertsnamnet til tenaren byrjar å løysast til ei ny adresse, har ein inaktiv klient ingen grunn til å merke det og ingen pakke frå det nye endepunktet å autentisere. Det problemet høyrer til gjenoppkoplingslogikk, til klienten si eiga atferd ved nye forsøk og til DNS, ikkje til float.

Å leggje til alternativet endå ein gong kompenserer ikkje for manglande rute til den nye adressa. Det hjelper heller ikkje når peeren er stille, for ein stille peer sender aldri den autentiserte pakken som ville flytte noko.

Brannmuren under har òg eit ord med i laget. Ein regel som berre tillèt det gamle ytre endepunktet blokkerer den endra adressa før OpenVPN i det heile ser ho, og ingen klientkonfigurasjon rettar det. Sjå gjennom livssyklusen for tillatne adresser som ei eiga oppgåve; å utvide regelen til kvar som helst kjelde byter eit lite problem mot eit stort.

Når NetworkManager eig profilen

Ein kommandolinjeprofil og ei importert tilkopling er separate konfigurasjonar, og å redigere den eine rører ikkje den andre. Før du reknar med at alternativet ikkje er støtta, må du fastslå kva plugintype den lagra profilen faktisk brukar og kvar verdiane bur. UUID-en til profilen er identifikatoren som tel når du granskar eller endrar noko.

Gransk den lagra tilkoplinga i staden for den opphavlege importfila. Ei linje som overlever i ei .ovpn-fil beviser ingenting viss den aktive behandlaren aldri brukte ho, og ein editor utan avkrysningsboks for eit gitt alternativ beviser heller ingenting om moglegheitene til protokollen.

Ikkje lapp ein pakka plugin for å leggje til åtferda, særleg ikkje med ein diff skriven for ein historisk versjon av ein urelatert komponent. Viss den installerte integrasjonen verkeleg ikkje kan uttrykkje innstillinga, er det rette trekket ein støtta profil eller ein annan klientveg godkjend av den som eig utrullinga.

Prov overgangen i staden for å rekne han med

Køyr testen slik feilen oppstår. Kople til, stadfest trafikk gjennom tunnelen, tving den ytre adressa til å endre seg, og kontroller deretter tre ting: økta finst framleis, den registrerte peer-adressa har flytta seg, og ein ekte førespurnad når framleis fram til målet. Alt mindre enn alle tre er eit delvis svar.

Hald gjenopprettingstilgang tilgjengeleg medan du testar, for roaming-forsøk har for vane å strande maskina du arbeider frå. Ein seriell konsoll eller ein rute utanfor bandet gjer ein mislukka test til ein fem minutts gjenoppretting i staden for eit besøk på staden.

Til slutt, skildre berre tilfellet du faktisk prøvde. Ei vellukka adresseendring i løpet av ei økt er ikkje bevis for at DNS-migreringar, ein annan klientimplementasjon eller ein gjenoppbygd profil vil te seg likt. link-options-dokumentasjonen oppgir omfanget av alternativet nøyaktig; testloggen din bør seie kva del av det omfanget du faktisk dekte.