Hoe MOBIKE een IKEv2 VPN in leven houdt wanneer het netwerk verandert

Een telefoon verlaat de Wi-Fi en stapt over op het mobiele netwerk, een laptop gaat van Ethernet naar een hotspot, en de IKEv2-tunnel overleeft of niet. MOBIKE is de uitbreiding die hem laat overleven, door de andere kant te vertellen dat het bronadres is veranderd in plaats van opnieuw te beginnen. Wat het niet doet, is elke applicatie tijdens de wisseling in leven houden. Dat zijn twee beweringen, en de tweede is wat mensen meestal bedoelen.

Doorloop de overgang in fasen, want elke fase faalt anders.

Wat de update werkelijk verandert

Zolang de beveiligingsassociatie nog geldig is, leert de initiator zijn nieuwe adres en stuurt een update naar de responder, die dat adres vervolgens voor dezelfde associatie gebruikt. De beveiligingsparameters worden niet opnieuw vanaf nul onderhandeld. Dat is het hele voordeel: geen nieuwe authenticatieronde, geen nieuwe sleuteluitwisseling, geen vraag aan de gebruiker. Het betekent ook dat de overlevende toestand nog steeds bij de oude sessie hoort.

MOBIKE kan het verkeer ook naar UDP-encapsulatie verplaatsen, waardoor een werkende tunnel na een netwerkwisseling soms poort 4500 gaat gebruiken. Die overgang bewijst op zichzelf niet dat NAT is gedetecteerd, ook al komen de twee vaak samen voor.

Schakelt uw profiel het echt in

Beide kanten moeten de uitbreiding ondersteunen, en de uitrol moet haar inschakelen. In strongSwan is het gedrag per verbinding configureerbaar, en wijzigingen aan interface of route kunnen indien nodig een padzoektocht en een update veroorzaken. Bekijk de werkelijke instellingen van de verbinding in plaats van aan te nemen dat elk IKEv2-profiel het inschakelt. Een profiel dat is gekopieerd uit een gids die ouder is dan de functie, is daar een veelvoorkomende oorzaak van.

De onderhandelde toestand aan beide uiteinden is de autoriteit, niet de documentatie van de productfamilie.

Doorloop de overgang in fasen

Leg de toestand van de applicatie vast voordat u van netwerk wisselt. Wissel dan, en leg daarna de toestand van de client en de server vast. Een ontbrekend adres, een onbereikbare tegenpartij en een applicatie die haar eigen sessie opnieuw moet verbinden, zijn drie verschillende uitkomsten. Alleen de eerste twee horen bij de VPN-laag; de derde hoort bij het protocol dat de applicatie spreekt.

Vergelijk een netwerkwissel met een stilstaande test, zodat u weet welke gebeurtenis het probleem veroorzaakt. Een doorvoermeting op het uiteindelijke netwerk kan een overgang niet nabootsen. Ze meet de bestemming, niet de reis.

Scheid de foutlagen

Een langdurige TCP-sessie kan mislukken door oorzaken buiten de IKEv2-uitwisseling. Het nieuwe netwerk kan anders filteren, anders resolveren of anders routeren. Het tunneladres verandert misschien helemaal niet terwijl het pad eronder verandert. Daarom kan een herverbinding van de applicatie iets repareren wat de VPN nooit heeft stukgemaakt.

Houd ook tijdens het herstel het blokkeringsbeleid in stand.

Automatische mobiliteit en een regel die direct verkeer voorkomt, zijn verschillende beheersmiddelen, en de tweede uitschakelen zodat de eerste werkt, is een slechte ruil. Als de mobiliteitsupdate mislukt, moet de blokkering standhouden in plaats van verkeer rond de tunnel te laten lekken.

Wat te registreren wanneer het zich herhaalt

Bewaar tijdstempels en beide adreswaarden van beide kanten. Dat verslag laat zien of de update voltooid was voordat de applicatie het contact verloor, wat het verschil is tussen een mobiliteitsfout en een time-out van de applicatie. Vergelijk daarna de wisselrichting: van Wi-Fi naar mobiel is niet symmetrisch met het omgekeerde. De ene richting kan werken terwijl de andere faalt.

Die asymmetrie is gewoon genoeg om het eerste te zijn dat u test.

Met het verslag in de hand houdt het incident op een nog een losgekoppeld pictogram te zijn en wordt het één gebeurtenis in een reeks met een bekende eigenaar. En dat is alles wat een doorloop eerlijk kan beloven.