Peer-adressen ændres midt i sessionen: hvad OpenVPN float gør

Bærbaren flytter fra kontorets Wi-Fi til et hotspot på telefonen, tunnelen holder et par sekunder endnu, og så stopper trafikken, mens grænsefladen stadig påstår, at den er forbundet. På serveren viser statuslisten fortsat den gamle offentlige adresse. Det er den situation, float findes til, og det er også den situation, hvor folk forventer, at det gør langt mere, end det gør. At få grænsen rigtigt gør et forvirrende stop til enten en konfigurationsændring på én linje eller en helt anden undersøgelse.

Hvad float lemper på, og hvad det aldrig lemper på

Normalt bliver en session ved med at tale med den ydre adresse og port, som den startede med, og pakker, der ankommer fra andre steder, ignoreres. Indstillingen float fjerner den strenge binding, når peeren først har bevist sig, så en ændret kildemapping kan fortsætte den samme session i stedet for at blive kasseret. Intet ved de kryptografiske kontroller ændres: nøgler, certifikater og enhver HMAC-beskyttelse forbliver præcis som konfigureret.

Det er en beslutning pr. pakke, ikke en politik om, hvem der må forbinde. En ukendt maskine, der sender en pakke fra en ny adresse, har ikke bevist noget, og dens pakke kasseres som enhver anden uautentificeret trafik. Kun trafik, der består sessionens egen autentificering, kan flytte den registrerede peer-adresse, og derfor er det sikkert at lade float være slået til i miljøer, hvor klienter roamer.

Det siger heller intet om den indre tunnel. En flyttet ydre adresse tildeler ikke en tunneladresse igen, ændrer ikke puljen og giver ikke peeren adgang til noget nyt. Inde i tunnelen gælder den samme identitet og de samme skubbede ruter før og efter flytningen. En roam forhandler heller ikke datakanalen igen, så den forhandlede cipher og nøgler fortsætter.

Pakken, der flytter en session, skal autentificere

Start en session på den sædvanlige måde mod det konfigurerede fjerne endepunkt, og float håndterer, hvad der sker, når mappingen ændres. En mobiloperatør, der omnummererer midt i flowet, en NAT-gateway, der omskriver sin portmapping, eller en bærbar, der skifter uplink, giver alle samme form: autentificerede pakker fra en ny tuple, der ankommer til en session, som stadig tror på den gamle.

Når du bliver spurgt, om float virker, er det nyttige bevis et fuldført handshake efterfulgt af en accepteret kildeændring, ikke en loglinje om adressen alene. Korrelér den gamle og den nye ydre adresse med den session, der blev ved med at leve, og bekræft derefter, at trafikken faktisk fortsatte gennem tunnelen.

Hvis sessionen dør i stedet for at flytte, mislykkedes pakken fra den nye adresse sandsynligvis i autentificering eller ankom slet ikke. Begge tilfælde ser ens ud fra klienten. På serveren fortæller en optagelse på den offentlige grænseflade dig hvilken, du har, før du rører ved nogen konfiguration.

Opdagelse er en helt separat mekanisme

float opløser ikke navne på en timer og sporer ikke en dynamisk DNS-post. Hvis serverens værtsnavn begynder at opløse til en ny adresse, har en inaktiv klient ingen grund til at bemærke det og ingen pakke fra det nye endepunkt at autentificere. Det problem hører til genopkoblingslogik, til klientens egen genforsøgsadfærd og til DNS, ikke til float.

At tilføje indstillingen endnu en gang kan ikke kompensere for at have ingen rute til den nye adresse. Det kan heller ikke hjælpe, når peeren er tavs, for en tavs peer sender aldrig den autentificerede pakke, der ville flytte noget.

Den underliggende firewall har også en stemme. En regel, der kun tillader det gamle ydre endepunkt, blokerer den ændrede adresse, før OpenVPN overhovedet ser den, og ingen mængde klientkonfiguration retter det. Gennemgå livscyklussen for tilladte adresser som en selvstændig opgave; at udvide reglen til enhver kilde bytter et lille problem for et stort.

Når NetworkManager ejer profilen

En kommandolinjeprofil og en importeret forbindelse er separate konfigurationer, og at redigere den ene rører ikke den anden. Før du antager, at indstillingen ikke understøttes, skal du fastslå, hvilken plugin-type den gemte profil faktisk bruger, og hvor dens værdier bor. Profilens UUID er den identifikator, der betyder noget, når du undersøger eller ændrer noget.

Undersøg den gemte forbindelse i stedet for den oprindelige importfil. En linje, der overlever i en .ovpn-fil, beviser intet, hvis den aktive manager aldrig anvendte den, og en editor uden afkrydsningsfelt for en given indstilling beviser heller intet om protokollens muligheder.

Lap ikke et pakket plugin for at tilføje adfærden, især ikke med en diff skrevet til en historisk version af en uvedkommende komponent. Hvis den installerede integration virkelig ikke kan udtrykke indstillingen, er det korrekte træk en understøttet profil eller en anden klientvej godkendt af den, der ejer udrulningen.

Bevis overgangen i stedet for at antage den

Kør testen, som fejlen sker. Forbind, verificér trafik gennem tunnelen, tving den ydre adresse til at ændre sig, og kontrollér så tre ting: sessionen findes stadig, den registrerede peer-adresse er flyttet, og en rigtig anmodning når stadig sin destination. Alt mindre end alle tre er et delvist svar.

Hold genopretningsadgang tilgængelig, mens du tester, for roaming-forsøg har for vane at strande den maskine, du arbejder fra. En seriel konsol eller en out-of-band-rute gør en mislykket test til en fem minutters genopretning i stedet for et besøg på stedet.

Endelig bør du kun beskrive det tilfælde, du har afprøvet. En vellykket adresseændring under en session er ikke bevis for, at DNS-migreringer, en anden klientimplementering eller en genopbygget profil vil opføre sig ens. link-options-dokumentationen angiver indstillingens omfang præcist; din testlog bør angive, hvilken del af det omfang du faktisk dækkede.