Peer-adressen ändrades mitt i sessionen: vad OpenVPN float gör

Den bärbara datorn flyttar från kontorets Wi-Fi till en telefonhotspot, tunneln håller i sig några sekunder till och sedan stannar trafiken medan gränssnittet fortfarande hävdar att det är anslutet. På servern visar statuslistan fortfarande den gamla publika adressen. Det här är situationen som float finns för, och det är också situationen där folk förväntar sig mycket mer av det än det gör. Att få gränsen rätt gör ett förvirrande stopp till antingen en konfigurationsändring på en rad eller en helt annan utredning.

Vad float luckrar upp, och vad det aldrig luckrar upp

Normalt fortsätter en session att tala med den yttre adress och port som den började med, och paket som kommer från andra håll ignoreras. Alternativet float tar bort den strikta bindningen när peeren väl har bevisat sig, så en ändrad källmappning kan fortsätta samma session i stället för att kastas. Ingenting i de kryptografiska kontrollerna ändras: nycklar, certifikat och allt HMAC-skydd förblir exakt som konfigurerat.

Det är ett beslut per paket, inte en policy om vem som får ansluta. En okänd maskin som skickar ett paket från en ny adress har inte bevisat något, och paketet kastas som all annan oautentiserad trafik. Bara trafik som passerar sessionens egen autentisering kan flytta den registrerade peer-adressen, och därför är det säkert att låta float vara på i miljöer där klienter rör sig.

Det säger inte heller något om den inre tunneln. En flyttad yttre adress tilldelar inte en tunneladress på nytt, ändrar inte poolen och ger inte peeren tillgång till något nytt. Inne i tunneln gäller samma identitet och samma knuffade rutter före och efter flytten. En roaming förhandlar inte heller om datakanalen, så den förhandlade chiffret och nycklarna fortsätter.

Paketet som flyttar en session måste autentiseras

Starta en session på vanligt sätt mot den konfigurerade fjärränden, och float hanterar det som händer när mappningen ändras. En mobiloperatör som numrerar om mitt i flödet, en NAT-gateway som skriver om sin portmappning eller en bärbar dator som byter uplänk ger alla samma form: autentiserade paket från en ny tupel, som anländer till en session som fortfarande tror på den gamla.

När du blir tillfrågad om float fungerar är det användbara beviset ett slutfört handskakning följt av en accepterad källändring, inte en loggrada om adressen enbart. Korrelera den gamla och den nya yttre adressen med sessionen som höll sig vid liv, och bekräfta sedan att trafiken faktiskt fortsatte genom tunneln.

Om sessionen dör i stället för att flytta sig misslyckades paketet från den nya adressen troligen med autentiseringen eller kom aldrig fram. Båda fallen ser identiska ut från klienten. På servern berättar en fångst på det publika gränssnittet vilket av dem du har innan du rör någon konfiguration.

Upptäckt är en helt separat mekanism

float löser inte namn på en timer och spårar inte en dynamisk DNS-post. Om serverns värdnamn börjar lösas till en ny adress har en inaktiv klient ingen anledning att märka det och inget paket från den nya slutpunkten att autentisera. Det problemet hör till återanslutningslogiken, till klientens eget återförsöksbeteende och till DNS, inte till float.

Att lägga till alternativet ännu en gång kompenserar inte för avsaknaden av en väg till den nya adressen. Det hjälper inte heller när peeren är tyst, eftersom en tyst peer aldrig skickar det autentiserade paket som skulle flytta något.

Brandväggen under har också ett ord med i laget. En regel som bara tillåter den gamla yttre slutpunkten blockerar den ändrade adressen innan OpenVPN ens ser den, och ingen klientkonfiguration åtgärdar det. Gå igenom livscykeln för tillåtna adresser som en egen uppgift; att vidga regeln till vilken källa som helst byter ett litet problem mot ett stort.

När NetworkManager äger profilen

En kommandoradsprofil och en importerad anslutning är separata konfigurationer, och att redigera den ena rör inte den andra. Innan du antar att alternativet inte stöds, fastställ vilken plugintyp den sparade profilen faktiskt använder och var dess värden bor. Profilens UUID är den identifierare som spelar roll när du granskar eller ändrar något.

Granska den sparade anslutningen i stället för den ursprungliga importfilen. En rad som överlever i en .ovpn-fil bevisar ingenting om den aktiva hanteraren aldrig tillämpade den, och en redigerare utan kryssruta för ett visst alternativ bevisar inte heller något om protokollets förmågor.

Lappa inte ett paketerat plugin för att lägga till beteendet, särskilt inte med en diff skriven för en historisk version av en orelaterad komponent. Om den installerade integrationen verkligen inte kan uttrycka inställningen är rätt steg en stödd profil eller en annan klientväg som godkänts av den som äger utrullningen.

Bevisa övergången i stället för att anta den

Kör testet så som felet uppstår. Anslut, verifiera trafik genom tunneln, tvinga den yttre adressen att ändras och kontrollera sedan tre saker: sessionen finns fortfarande, den registrerade peer-adressen har flyttats och en verklig begäran når fortfarande sitt mål. Allt mindre än alla tre är ett delvis svar.

Håll återställningsåtkomst tillgänglig medan du testar, för roaming-experiment har en tendens att stranda maskinen du arbetar från. En seriell konsol eller en väg utanför bandet gör ett misslyckat test till en fem minuters återställning i stället för ett besök på plats.

Beskriv slutligen bara det fall du faktiskt provade. En lyckad adressändring under en session är inte bevis för att DNS-migreringar, en annan klientimplementation eller en ombyggd profil beter sig likadant. link-options-dokumentationen anger alternativets omfattning exakt; din testlogg bör ange vilken del av den omfattningen du faktiskt täckte.