iPhone Always On VPN: twee tunnels kunnen één virtueel IP delen

Op een gecontroleerde iPhone met een beheerd Always On-profiel houdt de telefoon een tunnel per actieve IP-interface, zodat mobiel en Wi-Fi elk hun eigen tunnel krijgen. De server toont dan twee IKE-beveiligingsassociaties voor één apparaat, vaak met één virtueel adres gedeeld, en de eerste reflex is dat een rekey-lus noemen en timers gaan aanpassen. Die reflex is meestal onjuist. Doorloop de stappen hieronder in de volgorde waarin het bewijs op de server verschijnt, en laat de instellingen van de telefoon met rust tot de server je vertelt welk geval je hebt.

Begin met de twee regels die de server al heeft

Toon de associaties met swanctl --list-sas en lees vier velden over beide vermeldingen: het externe adres, de geauthenticeerde identiteit, het toegewezen virtuele IP en de aanmaaktijd. Twee verschillende buitenste adressen met één identiteit en één virtueel IP is de vorm die deze vraag begon, en het loont die op te schrijven vóór elke wijziging. Controleer daarna de kindassociaties die aan elk hangen, want de verkeersselectoren bepalen of een bestemmingsopzoeking de twee tunnels ooit zou kunnen onderscheiden. Een paar dat binnen seconden verschijnt en verdwijnt is een ander dier dan een paar waarvan beide uren leven.

Sorteer de lijst op aanmaaktijd voordat je een conclusie trekt. Nabijheid in de uitvoer betekent niets, en een tabelvormige lijst nodigt precies tot die fout uit.

Bepaal naar welke overlap je kijkt

IKEv2-rekey en make-before-break-herauthenticatie maken met opzet een korte overlap, door de nieuwe associatie op te bouwen voordat de oude wordt verwijderd. Tijdstempels beslissen de zaak, want een oude SA die een seconde of twee na de nieuwe verdwijnt, is vernieuwing die zijn werk doet. Onafhankelijke interfacetunnels zien er nooit zo uit, omdat elk blijft bestaan zolang zijn interface actief is en het verwijderen van de ene niet volgt uit het aanmaken van de andere.

Apples beheerde Always On-gedrag is per interface, daarom kan een gecontroleerd apparaat legitiem drukker lijken dan een met de hand ingesteld profiel. De automatische-verbindingsschakelaar van een provider-app betekent niet hetzelfde, en een gewone on-demand-regel ook niet. Het Apple-overzicht van de uitrol beschrijft het model per interface; vergelijk je twee regels ermee voordat je een lus aanneemt. Beide vormen putten ook uit dezelfde serverpool, dus de overlap is je enige vroege signaal.

Zie waarom één virtueel adres voor twee tunnels antwoorden breekt

Een antwoord aan de telefoon is geadresseerd aan het interne adres, en de kernel kiest een uitgaande tunnel op bestemming en beleid, niet op de interface die de telefoon gebruikte. Twee gelijktijdige associaties met hetzelfde virtuele IP en samenvallend beleid laten de routeringsbeslissing zonder manier om te zeggen bij welke sessie een antwoord hoort. Sommige antwoorden nemen de verkeerde tunnel, en de telefoon toont een verbinding die één kant op werkt of sterft wanneer Wi-Fi opkomt. Twee commando-uitvoer bewijzen de toestand: swanctl --list-sas toont hetzelfde virtuele IP op beide SA's, en ip xfrm policy toont twee identieke selectoren.

Precies dat paar uitvoer plak je in het wijzigingsrecord. Geen van beide is op zichzelf overtuigend, omdat elk afzonderlijk plausibel kan lijken.

Dit is adressering en beleid aan de serverkant, geen verkeerd gedrag van de telefoon, en geen enkele clientinstelling scheidt twee identieke interne adressen. De pool gaf dezelfde waarde twee keer uit en de beleidsinstallatie accepteerde die. Lees het resultaat vanaf de serverkant voordat je de client de schuld geeft.

Wijzig de pool of het gelijktijdigheidsmodel, niet de rekey-timer

In de swanctl-configuratie is uniciteit een expliciet beleid op de verbinding: unique = replace verwijdert een oudere verbinding wanneer een nieuwe tot stand komt, en unique = keep weigert de nieuwkomer. Beide waarden werken bij het opzetten van een verbinding, niet op de kind-SA's erin.

connections {
  ios-alwayson {
    unique = replace
  }
}

Geen van de waarden is neutraal voor een client per interface. keep herstelt een net statusscherm door de tweede tunnel te weigeren en breekt het beheerde ontwerp, terwijl replace de oudere tunnel neerhaalt en hetzelfde compromis de andere kant op is. Als beide tunnels echt nodig zijn, moet de backend van de pool verschillende leases voor één identiteit uitgeven, en de lease-sleutel moet de verzoeken onderscheiden. Een statische identiteit-naar-adres-tabel geeft graag twee keer hetzelfde adres terug en reproduceert het oorspronkelijke probleem met meer configuratie. Controleer hoe de backend leases sleutelt voordat je een tweede statische mapping toevoegt.

Test de overgangen die je echt uitrolt

Loop met een actieve sessie buiten het Wi-Fi-bereik, loop dan weer naar binnen, en controleer dat antwoorden in beide richtingen aankomen. Doe dat twee keer, want bij de tweede overgang duikt meestal een verouderd beleid op. Test met een dienst die antwoordt op de verbinding die je hebt geopend, en herhaal het naar buiten lopen terwijl de tunnel verkeer draagt in plaats van stil te staan. Een telefoon die kan zenden maar niet ontvangen, ziet er gezond uit in een handshake-log en kapot in een browser.

Een statusscherm dat tot één regel is teruggebracht is geen bewijs van een werkend ontwerp, alleen bewijs dat één tunnel weg is. Beide richtingen moeten werken voordat een overgang slaagt. Schrijf op wat je hebt waargenomen, samen met de twee uitvoer van de overlapcontrole, zodat de volgende engineer kan vergelijken in plaats van het rondje te herhalen.