Hur MOBIKE håller en IKEv2 VPN vid liv när nätverket byts

En telefon lämnar Wi-Fi och ansluter till mobilnätet, en bärbar dator flyttar från Ethernet till en hotspot, och IKEv2-tunneln överlever eller inte. MOBIKE är tillägget som låter den överleva, genom att tala om för den andra änden att källadressen har ändrats i stället för att börja om. Vad det inte gör är att hålla varje applikation vid liv under bytet. Det är två påståenden, och det andra är det folk vanligtvis menar.

Gå igenom övergången i etapper, eftersom varje etapp misslyckas olika.

Vad uppdateringen faktiskt ändrar

Så länge säkerhetsassociationen fortfarande är giltig lär sig initiativtagaren sin nya adress och skickar en uppdatering till svararen, som sedan använder den adressen för samma association. Säkerhetsparametrarna förhandlas inte om från grunden. Det är hela fördelen: ingen ny autentiseringsrunda, inget nytt nyckelutbyte, ingen fråga till användaren. Det betyder också att det överlevande tillståndet fortfarande tillhör den gamla sessionen.

MOBIKE kan också flytta trafiken till UDP-inkapsling, vilket är varför en fungerande tunnel ibland börjar använda port 4500 efter ett nätverksbyte. Den övergången bevisar inte i sig att NAT upptäcktes, även om de två ofta uppträder tillsammans.

Aktiverar din profil det verkligen

Båda parter måste stödja tillägget, och driftsättningen måste aktivera det. I strongSwan kan beteendet konfigureras per anslutning, och ändringar av gränssnitt eller rutt kan utlösa en sökning efter väg och en uppdatering vid behov. Granska anslutningens faktiska inställningar i stället för att anta att varje IKEv2-profil slår på det. En profil som kopierats från en guide som är äldre än funktionen är en vanlig orsak till detta.

Det förhandlade tillståndet i båda ändar är auktoriteten, inte dokumentationen för produktfamiljen.

Gå igenom övergången i etapper

Registrera applikationens tillstånd innan du byter nätverk. Byt sedan, och registrera därefter klientens och serverns tillstånd. En saknad adress, en onåbar motpart och en applikation som själv måste återansluta sin session är tre olika utfall. Bara de två första hör till VPN-lagret; det tredje hör till det protokoll applikationen talar.

Jämför ett nätverksbyte med ett stationärt test, så att du vet vilken händelse som utlöser problemet. En genomströmningsmätning i det slutliga nätverket kan inte återskapa en övergång. Den mäter destinationen, inte resan.

Separera fellagren

En långvarig TCP-session kan misslyckas av skäl utanför IKEv2-utbytet. Det nya nätverket kan filtrera, slå upp eller routa annorlunda. Tunneladressen kanske inte ändras alls medan vägen under den ändras. Därför kan en återanslutning från applikationen reparera något som VPN aldrig förstörde.

Håll blockeringspolicyn på plats även under återställningen.

Automatisk mobilitet och en regel som hindrar direkt trafik är olika kontroller, och att stänga av den andra för att den första ska fungera är ett dåligt byte. Om mobilitetsuppdateringen misslyckas bör blockeringen hålla i stället för att läcka trafik runt tunneln.

Vad som ska registreras när det upprepas

Spara tidsstämplar och båda adressvärdena från båda sidor. Den registreringen visar om uppdateringen slutfördes innan applikationen tappade kontakten, vilket är skillnaden mellan ett mobilitetsfel och en tidsgräns i applikationen. Jämför sedan bytets riktning: att lämna Wi-Fi till förmån för mobilnätet är inte symmetriskt med det omvända. Den ena riktningen kan fungera medan den andra misslyckas.

Den asymmetrin är vanlig nog att vara det första du bör testa.

Med registreringen i handen slutar händelsen vara ännu en frånkopplad ikon och blir en händelse i en sekvens med en känd ägare. Och det är allt en genomgång ärligt kan lova.