Peer-adressen endres midt i økten: hva OpenVPN float gjør

Bærbaren flytter fra kontorets Wi-Fi til et hotspot på telefonen, tunnelen holder et par sekunder til, og så stopper trafikken mens grensesnittet fortsatt hevder at det er tilkoblet. På serveren viser statuslisten fortsatt den gamle offentlige adressen. Dette er situasjonen float finnes for, og det er også situasjonen der folk forventer langt mer av det enn det gjør. Å få grensen riktig gjør en forvirrende stans om til enten en konfigurasjonsendring på én linje eller en helt annen undersøkelse.

Hva float lemper på, og hva det aldri lemper på

Normalt fortsetter en økt å snakke med den ytre adressen og porten den startet med, og pakker som kommer fra andre steder ignoreres. Alternativet float fjerner den strenge bindingen når peeren først har bevist seg, slik at en endret kildeadressemapping kan fortsette samme økt i stedet for å bli forkastet. Ingenting ved de kryptografiske kontrollene endres: nøkler, sertifikater og enhver HMAC-beskyttelse forblir nøyaktig som konfigurert.

Dette er en avgjørelse per pakke, ikke en policy om hvem som får koble til. En ukjent maskin som sender en pakke fra en ny adresse har ikke bevist noe, og pakken forkastes som all annen uautentisert trafikk. Bare trafikk som passerer øktens egen autentisering kan flytte den registrerte peer-adressen, og derfor er det trygt å la float stå på i miljøer der klienter roamer.

Det sier heller ingenting om den indre tunnelen. En flyttet ytre adresse tildeler ikke en tunneladresse på nytt, endrer ikke bassenget og gir ikke peeren tilgang til noe nytt. Inne i tunnelen gjelder samme identitet og samme dyttede ruter før og etter flyttingen. En roam forhandler heller ikke datakanalen på nytt, så den forhandlede chifferen og nøklene fortsetter.

Pakken som flytter en økt, må autentiseres

Start en økt på vanlig måte mot den konfigurerte eksterne enden, og float håndterer det som skjer når mappingen endres. En mobiloperatør som omnummererer midt i flyten, en NAT-gateway som skriver om portmappingen sin, eller en bærbar som bytter uplink gir alle samme form: autentiserte pakker fra en ny tuple, som ankommer en økt som fortsatt tror på den gamle.

Når du blir spurt om float virker, er det nyttige beviset et fullført håndtrykk etterfulgt av en akseptert kildeendring, ikke en logglinje om adressen alene. Korreler den gamle og den nye ytre adressen med økten som holdt seg i live, og bekreft deretter at trafikken faktisk fortsatte gjennom tunnelen.

Hvis økten dør i stedet for å flytte seg, mislyktes pakken fra den nye adressen sannsynligvis i autentisering eller kom ikke frem i det hele tatt. Begge tilfellene ser like ut fra klienten. På serveren forteller en fangst på det offentlige grensesnittet deg hvilken du har før du rører noen konfigurasjon.

Oppdagelse er en helt separat mekanisme

float løser ikke navn på en timer og sporer ikke en dynamisk DNS-post. Hvis serverens vertsnavn begynner å løse til en ny adresse, har en inaktiv klient ingen grunn til å merke det og ingen pakke fra det nye endepunktet å autentisere. Det problemet hører til gjenoppkoblingslogikk, til klientens egen nytt-forsøk-atferd og til DNS, ikke til float.

Å legge til alternativet enda en gang kompenserer ikke for manglende rute til den nye adressen. Det hjelper heller ikke når peeren er stille, for en stille peer sender aldri den autentiserte pakken som ville flyttet noe.

Brannmuren under har også et ord med i laget. En regel som bare tillater det gamle ytre endepunktet blokkerer den endrede adressen før OpenVPN i det hele tatt ser den, og ingen klientkonfigurasjon retter det. Se gjennom livssyklusen for tillatte adresser som en egen oppgave; å utvide regelen til enhver kilde bytter et lite problem mot et stort.

Når NetworkManager eier profilen

En kommandolinjeprofil og en importert tilkobling er separate konfigurasjoner, og å redigere den ene rører ikke den andre. Før du antar at alternativet ikke støttes, må du fastslå hvilken plugintype den lagrede profilen faktisk bruker og hvor verdiene bor. Profilens UUID er identifikatoren som betyr noe når du inspiserer eller endrer noe.

Inspiser den lagrede tilkoblingen i stedet for den opprinnelige importfilen. En linje som overlever i en .ovpn-fil beviser ingenting hvis den aktive behandleren aldri brukte den, og en editor uten avkrysningsboks for et gitt alternativ beviser heller ingenting om protokollens muligheter.

Ikke lapp en pakket plugin for å legge til atferden, særlig ikke med en diff skrevet for en historisk versjon av en urelatert komponent. Hvis den installerte integrasjonen virkelig ikke kan uttrykke innstillingen, er det riktige trekket en støttet profil eller en annen klientvei godkjent av den som eier utrullingen.

Bevis overgangen i stedet for å anta den

Kjør testen slik feilen oppstår. Koble til, verifiser trafikk gjennom tunnelen, tving den ytre adressen til å endre seg, og kontroller deretter tre ting: økten finnes fortsatt, den registrerte peer-adressen har flyttet seg, og en ekte forespørsel når fortsatt frem til målet. Alt mindre enn alle tre er et delsvar.

Hold gjenopprettingstilgang tilgjengelig mens du tester, for roaming-forsøk har for vane å strande maskinen du arbeider fra. En seriell konsoll eller en rute utenfor båndet gjør en mislykket test til en fem minutters gjenoppretting i stedet for et stedlig besøk.

Til slutt, beskriv bare tilfellet du faktisk prøvde. En vellykket adresseendring i løpet av en økt er ikke bevis for at DNS-migreringer, en annen klientimplementasjon eller en gjenoppbygd profil vil oppføre seg likt. link-options-dokumentasjonen oppgir omfanget av alternativet presist; testloggen din bør si hvilken del av det omfanget du faktisk dekket.