Hvordan MOBIKE holder en IKEv2 VPN i live, når netværket skifter

En telefon forlader Wi-Fi og skifter til mobilnetværket, en bærbar computer flytter fra Ethernet til et hotspot, og IKEv2-tunnelen overlever eller gør ikke. MOBIKE er den udvidelse, der får den til at overleve ved at fortælle den fjerne ende, at kildeadressen er ændret, i stedet for at starte forfra. Det, den ikke gør, er at holde hvert program i live gennem skiftet. Det er to påstande, og det er den anden, folk som regel mener.

Gå gennem overgangen i etaper, fordi hver etape fejler forskelligt.

Hvad opdateringen faktisk ændrer

Mens sikkerhedsassociationen stadig er gyldig, får initiativtageren sin nye adresse og sender en opdatering til svareren, som derefter bruger den adresse til den samme association. Sikkerhedsparametrene forhandles ikke forfra. Det er hele fordelen: ingen ny godkendelsesrunde, ingen ny nøgleudveksling, ingen forespørgsel til brugeren. Det betyder også, at den overlevende tilstand stadig tilhører den gamle session.

MOBIKE kan også flytte trafik til UDP-indkapsling, og derfor begynder en fungerende tunnel nogle gange at bruge port 4500 efter et netværksskift. Den overgang beviser ikke i sig selv, at NAT blev opdaget, selvom de to ofte optræder sammen.

Aktiverer din profil det virkelig

Begge parter skal understøtte udvidelsen, og udrulningen skal aktivere den. I strongSwan kan adfærden konfigureres per forbindelse, og ændringer i grænseflade eller rute kan udløse en stisøgning og en opdatering, når det er nødvendigt. Undersøg forbindelsens faktiske indstillinger i stedet for at antage, at hver IKEv2-profil slår det til. En profil kopieret fra en vejledning, der er ældre end funktionen, er en almindelig årsag til dette.

Den forhandlede tilstand i begge ender er autoriteten, ikke dokumentationen for produktfamilien.

Gå gennem overgangen i etaper

Registrér programmets tilstand, før du skifter netværk. Skift derefter, og registrér klientens og serverens tilstand bagefter. En manglende adresse, en utilgængelig modpart og et program, der selv skal genoprette sin session, er tre forskellige udfald. Kun de to første hører til VPN-laget; det tredje hører til den protokol, som programmet taler.

Sammenlign et netværksskift med en stationær test, så du ved, hvilken begivenhed der udløser problemet. En gennemstrømningsmåling på det endelige netværk kan ikke genskabe en overgang. Den måler destinationen, ikke rejsen.

Adskil fejllagene

En langvarig TCP-session kan fejle af årsager uden for IKEv2-udvekslingen. Det nye netværk kan filtrere, opløse eller route anderledes. Tunnelens adresse ændrer sig måske slet ikke, mens stien under den gør. Derfor kan en genoprettet programforbindelse rette noget, som VPN'en aldrig brød.

Hold blokeringspolitikken på plads, mens du genopretter, også.

Automatisk mobilitet og en regel, der forhindrer direkte trafik, er forskellige kontroller, og at slå den anden fra for at få den første til at virke er en dårlig handel. Hvis mobilitetsopdateringen fejler, bør blokeringen holde i stedet for at lække trafik uden om tunnelen.

Hvad skal registreres, når det gentager sig

Bevar tidsstempler og begge adresseværdier fra begge sider. Den registrering viser, om opdateringen blev fuldført, før programmet mistede kontakten, hvilket er forskellen mellem en mobilitetsfejl og en programtimeout. Sammenlign derefter skifteretningen: at forlade Wi-Fi til fordel for mobilnetværket er ikke symmetrisk med det modsatte. Den ene retning kan virke, mens den anden fejler.

Denne asymmetri er almindelig nok til at være det første, du bør teste.

Med registreringen i hånden holder hændelsen op med at være endnu et afbrudt ikon og bliver én begivenhed i en sekvens med en kendt ejer. Og det er alt, hvad en gennemgang ærligt kan love.