Cum menține MOBIKE o conexiune VPN IKEv2 activă atunci când rețeaua se schimbă

Un telefon părăsește Wi-Fi și se alătură rețelei mobile, un laptop trece de la Ethernet la un hotspot, iar tunelul IKEv2 fie supraviețuiește, fie nu. MOBIKE este extensia care îl lasă să supraviețuiască, spunând capătului îndepărtat că adresa sursă s-a schimbat în loc să o ia de la capăt. Ce nu face este să mențină fiecare aplicație activă pe durata schimbării. Sunt două afirmații, iar a doua este cea la care se gândesc de obicei oamenii.

Parcurgeți tranziția în etape, pentru că fiecare etapă eșuează altfel.

Ce schimbă de fapt actualizarea

Atât timp cât asocierea de securitate este încă validă, inițiatorul își află noua adresă și trimite o actualizare respondențului, care folosește apoi acea adresă pentru aceeași asociere. Parametrii de securitate nu sunt renegociați de la zero. Acesta este tot beneficiul: nicio rundă nouă de autentificare, niciun schimb nou de chei, nicio solicitare către utilizator. Înseamnă și că starea supraviețuitoare aparține încă sesiunii vechi.

MOBIKE poate muta și traficul în încapsulare UDP, motiv pentru care un tunel funcțional începe uneori să folosească portul 4500 după o schimbare de rețea. Acea tranziție nu dovedește prin ea însăși că NAT a fost detectat, deși cele două apar adesea împreună.

Profilul dumneavoastră îl activează într-adevăr

Ambele părți trebuie să accepte extensia, iar implementarea trebuie să o activeze. În strongSwan comportamentul este configurabil pentru fiecare conexiune, iar modificările de interfață sau de rută pot declanșa o căutare de cale și o actualizare atunci când este necesar. Inspectați setările reale ale conexiunii în loc să presupuneți că fiecare profil IKEv2 o activează. Un profil copiat dintr-un ghid anterior acestei funcții este o sursă obișnuită a acestui lucru.

Starea negociată la ambele capete este autoritatea, nu documentația familiei de produse.

Parcurgeți tranziția în etape

Înregistrați starea aplicației înainte de a schimba rețelele. Apoi schimbați, și înregistrați după aceea starea clientului și a serverului. O adresă lipsă, un partener inaccesibil și o aplicație care trebuie să-și reconecteze propria sesiune sunt trei rezultate diferite. Doar primele două aparțin stratului VPN; al treilea aparține protocolului pe care îl vorbește aplicația.

Comparați o schimbare de rețea cu un test staționar, ca să știți ce eveniment declanșează problema. O măsurare a debitului în rețeaua finală nu poate reproduce o tranziție. Măsoară destinația, nu călătoria.

Separați straturile de eșec

O sesiune TCP de lungă durată poate eșua din motive din afara schimbului IKEv2. Noua rețea poate filtra, rezolva sau ruta diferit. Adresa tunelului poate să nu se schimbe deloc în timp ce calea de dedesubt se schimbă. De aceea o reconectare a aplicației poate repara ceva ce VPN-ul nu a stricat niciodată.

Păstrați politica de blocare în vigoare și în timpul recuperării.

Mobilitatea automată și o regulă care împiedică traficul direct sunt controale diferite, iar dezactivarea celei de-a doua pentru ca prima să funcționeze este un schimb prost. Dacă actualizarea de mobilitate eșuează, blocarea ar trebui să reziste în loc să lase traficul să scape în jurul tunelului.

Ce să înregistrați când se repetă

Păstrați marcajele de timp și ambele valori de adresă din ambele părți. Acea înregistrare arată dacă actualizarea s-a încheiat înainte ca aplicația să piardă contactul, ceea ce este diferența dintre o eroare de mobilitate și un timeout al aplicației. Apoi comparați direcția schimbării: plecarea din Wi-Fi către rețeaua mobilă nu este simetrică cu inversul. O direcție poate funcționa în timp ce cealaltă eșuează.

Acea asimetrie este destul de obișnuită pentru a fi primul lucru de testat.

Cu înregistrarea în mână, incidentul încetează să mai fie încă o pictogramă deconectată și devine un eveniment într-o secvență cu un proprietar cunoscut. Și asta este tot ce poate promite sincer o parcurgere.