Hvordan MOBIKE holder en IKEv2 VPN i live når nettverket endres

En telefon forlater Wi-Fi og kobler seg til mobilnettet, en bærbar PC flytter fra Ethernet til et hotspot, og IKEv2-tunnelen overlever eller ikke. MOBIKE er utvidelsen som lar den overleve, ved å fortelle den andre enden at kildeadressen er endret i stedet for å starte på nytt. Det den ikke gjør, er å holde hver applikasjon i live gjennom endringen. Det er to påstander, og det er den andre folk vanligvis mener.

Gå gjennom overgangen i etapper, fordi hver etappe feiler på ulikt vis.

Hva oppdateringen faktisk endrer

Så lenge sikkerhetsassosiasjonen fortsatt er gyldig, lærer initiativtakeren sin nye adresse og sender en oppdatering til svareren, som deretter bruker den adressen for den samme assosiasjonen. Sikkerhetsparameterne forhandles ikke på nytt fra bunnen. Det er hele fordelen: ingen ny autentiseringsrunde, ingen ny nøkkelutveksling, ingen forespørsel til brukeren. Det betyr også at den overlevende tilstanden fortsatt tilhører den gamle økten.

MOBIKE kan også flytte trafikken til UDP-innkapsling, og derfor begynner en fungerende tunnel noen ganger å bruke port 4500 etter et nettverksbytte. Den overgangen beviser ikke i seg selv at NAT ble oppdaget, selv om de to ofte opptrer sammen.

Aktiverer profilen din det egentlig

Begge parter må støtte utvidelsen, og utrullingen må aktivere den. I strongSwan kan atferden konfigureres per tilkobling, og endringer i grensesnitt eller rute kan utløse et stisøk og en oppdatering når det trengs. Undersøk de faktiske innstillingene til tilkoblingen i stedet for å anta at hver IKEv2-profil slår den på. En profil kopiert fra en veiledning som er eldre enn funksjonen, er en vanlig årsak til dette.

Den forhandlede tilstanden i begge ender er autoriteten, ikke dokumentasjonen for produktfamilien.

Gå gjennom overgangen i etapper

Registrer applikasjonens tilstand før du bytter nettverk. Bytt deretter, og registrer tilstanden til klienten og serveren etterpå. En manglende adresse, en utilgjengelig part og en applikasjon som selv må koble til økten på nytt, er tre ulike utfall. Bare de to første hører til VPN-laget; det tredje hører til protokollen applikasjonen snakker.

Sammenlign et nettverksbytte med en stasjonær test, slik at du vet hvilken hendelse som utløser problemet. En gjennomstrømningsmåling på det endelige nettverket kan ikke gjenskape en overgang. Den måler destinasjonen, ikke reisen.

Skill feillagene

En langvarig TCP-økt kan feile av årsaker utenfor IKEv2-utvekslingen. Det nye nettverket kan filtrere, slå opp eller rute annerledes. Tunneladressen endres kanskje ikke i det hele tatt mens stien under den endres. Derfor kan en ny tilkobling fra applikasjonen rette noe VPN aldri ødela.

Hold blokkeringspolicyen på plass mens du gjenoppretter, også.

Automatisk mobilitet og en regel som hindrer direkte trafikk er forskjellige kontroller, og å slå av den andre for at den første skal virke er en dårlig handel. Hvis mobilitetsoppdateringen feiler, bør blokkeringen holde i stedet for å lekke trafikk rundt tunnelen.

Hva som skal registreres når det gjentar seg

Behold tidsstempler og begge adresseverdiene fra begge sider. Den registreringen viser om oppdateringen ble fullført før applikasjonen mistet kontakten, som er forskjellen mellom en mobilitetsfeil og en tidsavbrudd i applikasjonen. Sammenlign så bytteretningen: å forlate Wi-Fi til fordel for mobilnettet er ikke symmetrisk med det motsatte. Den ene retningen kan virke mens den andre feiler.

Den asymmetrien er vanlig nok til å være det første du bør teste.

Med registreringen i hånden slutter hendelsen å være nok et frakoblet ikon og blir én hendelse i en sekvens med en kjent eier. Og det er alt en gjennomgang ærlig kan love.