iPhone Always On VPN: två tunnlar kan dela en virtuell IP

På en övervakad iPhone med en hanterad Always On-profil håller telefonen en tunnel för varje aktivt IP-gränssnitt, så mobilnät och Wi-Fi får varsin. Servern listar sedan två IKE-säkerhetsassociationer för en enhet, ofta med en gemensam virtuell adress, och den första impulsen är att kalla det en rekey-loop och börja ändra timers. Den impulsen är oftast fel. Gå igenom stegen nedan i den ordning bevisen dyker upp på servern, och låt telefonens inställningar vara ifred tills servern säger vilket fall du har.

Börja med de två rader servern redan har

Lista associationerna med swanctl --list-sas och läs fyra fält i båda posterna: fjärradressen, den autentiserade identiteten, den tilldelade virtuella IP:n och skapandetiden. Två olika yttre adresser med en identitet och en virtuell IP är den form som startade frågan, och det är värt att skriva ned den före varje ändring. Kontrollera sedan de underordnade associationerna som hänger på var och en, eftersom trafikväljarna avgör om en destinationssökning någonsin skulle kunna skilja de två tunnlarna åt. Ett par som dyker upp och försvinner inom sekunder är ett annat djur än ett par där båda lever i timmar.

Sortera listan efter skapandetid innan du drar en slutsats. Grannskap i utdata betyder ingenting, och en tabellformad lista bjuder in precis till det felet.

Avgör vilken överlappning du tittar på

IKEv2-rekey och make-before-break-reautentisering skapar med avsikt en kort överlappning, genom att etablera den nya associationen innan den gamla raderas. Tidsstämplar avgör fallet, eftersom en gammal SA som försvinner en sekund eller två efter att den nya dykt upp är förnyelse som gör sitt jobb. Oberoende gränssnittstunnlar ser aldrig ut så, eftersom var och en består så länge dess gränssnitt är uppe, och radering av den ena följer inte av skapandet av den andra.

Apples hanterade Always On-beteende är per gränssnitt, därför kan en övervakad enhet med rätta se upptagen ut än en profil som ställts in för hand. En leverantörsapps automatikbrytare betyder inte samma sak, och en vanlig on-demand-regel gör det inte heller. Apples översikt över utrullning beskriver modellen per gränssnitt; jämför dina två rader med den innan du antar en loop. Båda formerna hämtar också från samma serverpool, så överlappningen är din enda tidiga signal.

Se varför en virtuell adress för två tunnlar bryter svaren

Ett svar till telefonen adresseras till den inre adressen, och kärnan väljer en utgående tunnel efter destination och policy, inte efter gränssnittet telefonen använde. Två samtidiga associationer som håller samma virtuella IP med sammanfallande policyer lämnar routingbeslutet utan sätt att säga vilken session ett svar hör till. Vissa svar tar fel tunnel, och telefonen visar en anslutning som fungerar åt ena hållet eller dör när Wi-Fi kommer upp. Två kommandoutdata bevisar tillståndet: swanctl --list-sas visar samma virtuella IP på båda SA:erna, och ip xfrm policy visar två identiska väljare.

Just det paret utdata klistrar du in i ändringsprotokollet. Ingen av dem är övertygande ensam, eftersom var och en kan se rimlig ut för sig.

Det här är adressering och policy på serversidan, inte felaktigt beteende från telefonen, och ingen klientinställning skiljer två identiska inre adresser åt. Poolen delade ut samma värde två gånger och policyinstallatören accepterade det. Läs resultatet från serversidan innan du skyller på klienten.

Ändra poolen eller samtidighetsmodellen, inte rekey-timern

I swanctl-konfigurationen är unikhet en uttrycklig policy på anslutningen: unique = replace tar bort en äldre anslutning när en ny upprättas, och unique = keep avvisar den nya. Båda värdena verkar när en anslutning sätts upp, inte på de underordnade SA:erna i den.

connections {
  ios-alwayson {
    unique = replace
  }
}

Inget av värdena är neutralt för en klient per gränssnitt. keep återställer en städad statusskärm genom att avvisa den andra tunneln och bryter den hanterade designen, medan replace river ned den äldre tunneln och är samma kompromiss åt andra hållet. Om båda tunnlarna verkligen behövs måste poolens backend utfärda olika leases för en identitet, och dess lease-nyckel måste skilja förfrågningarna åt. En statisk identitet-till-adress-tabell återkommer gärna med samma adress två gånger och återskapar det ursprungliga problemet med mer konfiguration. Kontrollera hur backend:en nycklar leases innan du lägger till en andra statisk mappning.

Testa de övergångar du faktiskt rullar ut

Gå ut ur Wi-Fi-räckvidden med en aktiv session, gå sedan in igen, och kontrollera att svar anländer i båda riktningarna. Gör det två gånger, eftersom den andra övergången är där en inaktuell policy oftast dyker upp. Testa med en tjänst som svarar på anslutningen du öppnade, och upprepa utegången medan tunneln bär trafik i stället för att stå still. En telefon som kan skicka men inte ta emot ser frisk ut i en handshake-logg och trasig ut i en webbläsare.

En statusskärm som reducerats till en rad är inte bevis på en fungerande design, bara bevis på att en tunnel är borta. Båda riktningarna måste fungera innan en övergång godkänns. Skriv ned vad du observerade, tillsammans med de två utdata från överlappningskontrollen, så att nästa ingenjör kan jämföra i stället för att upprepa promenaden.