Korleis MOBIKE held ein IKEv2 VPN i live når nettet blir endra

Ein telefon forlèt Wi-Fi og koplar seg til mobilnettet, ein berbar PC flyttar frå Ethernet til eit hotspot, og IKEv2-tunnelen overlever eller ikkje. MOBIKE er utvidinga som lèt han overleve, ved å fortelje den andre enden at kjeldeadressa er endra i staden for å starte på nytt. Det han ikkje gjer, er å halde kvar applikasjon i live gjennom endringa. Det er to påstandar, og det er den andre folk vanlegvis meiner.

Gå gjennom overgangen i etappar, fordi kvar etappe feilar på ulikt vis.

Kva oppdateringa faktisk endrar

Så lenge tryggleiksassosiasjonen framleis er gyldig, lærer initiativtakaren si nye adresse og sender ei oppdatering til svararen, som deretter brukar den adressa for den same assosiasjonen. Tryggleiksparameterane blir ikkje forhandla på nytt frå botnen. Det er heile fordelen: inga ny autentiseringsrunde, inga ny nøkkelutveksling, inga førespurnad til brukaren. Det tyder òg at den overlevande tilstanden framleis høyrer til den gamle økta.

MOBIKE kan òg flytte trafikken til UDP-innkapsling, og difor byrjar ein fungerande tunnel av og til å bruke port 4500 etter eit nettverksbyte. Den overgangen bevisar ikkje i seg sjølv at NAT vart oppdaga, sjølv om dei to ofte opptrer saman.

Slår profilen din det eigentleg på

Båe partar må støtte utvidinga, og utrullinga må slå henne på. I strongSwan kan åtferda konfigurerast per tilkopling, og endringar i grensesnitt eller rute kan utløyse eit stisøk og ei oppdatering når det trengst. Undersøk dei faktiske innstillingane til tilkoplinga i staden for å gå ut frå at kvar IKEv2-profil slår henne på. Ein profil kopiert frå ei rettleiing som er eldre enn funksjonen, er ei vanleg årsak til dette.

Den forhandla tilstanden i båe endar er autoriteten, ikkje dokumentasjonen for produktfamilien.

Gå gjennom overgangen i etappar

Registrer tilstanden til applikasjonen før du byter nett. Bytt deretter, og registrer tilstanden til klienten og serveren etterpå. Ei manglande adresse, ein utilgjengeleg part og ein applikasjon som sjølv må kople økta si på nytt, er tre ulike utfall. Berre dei to første høyrer til VPN-laget; det tredje høyrer til protokollen applikasjonen snakkar.

Samanlikn eit nettverksbyte med ein stasjonær test, slik at du veit kva hending som utløyser problemet. Ei gjennomstrøymingsmåling på det endelege nettet kan ikkje attskape ein overgang. Ho måler destinasjonen, ikkje reisa.

Skil feillaga

Ei langvarig TCP-økt kan feile av årsaker utanfor IKEv2-utvekslinga. Det nye nettet kan filtrere, slå opp eller rute annleis. Tunneladressa blir kanskje ikkje endra i det heile medan stien under henne blir endra. Difor kan ein ny tilkopling frå applikasjonen rette noko VPN aldri øydela.

Hald blokkeringspolitikken på plass medan du attopprettar, òg.

Automatisk mobilitet og ein regel som hindrar direkte trafikk er ulike kontrollar, og å slå av den andre for at den første skal verke er ein dårleg handel. Viss mobilitetsoppdateringa feilar, bør blokkeringa halde i staden for å lekke trafikk rundt tunnelen.

Kva som skal registrerast når det gientek seg

Hald på tidsstemplar og båe adresseverdiane frå båe sider. Den registreringa viser om oppdateringa vart fullført før applikasjonen mista kontakten, som er skilnaden mellom ein mobilitetsfeil og ein timeout i applikasjonen. Samanlikn så byteretninga: å forlate Wi-Fi til fordel for mobilnettet er ikkje symmetrisk med det motsette. Den eine retninga kan verke medan den andre feilar.

Den asymmetrien er vanleg nok til å vere det første du bør teste.

Med registreringa i handa sluttar hendinga å vere eit nok eit fråkopla ikon og blir éi hending i ein sekvens med ein kjend eigar. Og det er alt ein gjennomgang ærleg kan love.