iPhone Always On VPN: to tunnelar kan dele éin virtuell IP

På ein overvaka iPhone med ein administrert Always On-profil held telefonen ein tunnel for kvart aktive IP-grensesnitt, slik at mobilnett og Wi-Fi får kvar sin. Tenaren viser deretter to IKE-tryggleiksassosiasjonar for éi eining, ofte med éin virtuell adresse til felles, og den første innskytelsen er å kalle det ei rekey-løkke og byrje å endre timar. Den innskytelsen er som regel feil. Gå gjennom trinna nedanfor i den rekkjefølgja prova dukkar opp på tenaren, og lat innstillingane på telefonen vere i fred til tenaren fortel deg kva tilfelle du har.

Byrj med dei to radene tenaren allereie har

List assosiasjonane med swanctl --list-sas og les fire felt på tvers av begge oppføringane: fjernadressa, den autentiserte identiteten, den tildelte virtuelle IP-en og opprettingstida. To ulike ytre adresser med éin identitet og éin virtuell IP er forma som starta dette spørsmålet, og det er verdt å skrive ho ned før kvar endring. Sjekk deretter underassosiasjonane som heng på kvar av dei, fordi trafikkveljarane avgjer om eit destinasjonsoppslag nokon gong kunne skilje dei to tunnelane. Eit par som dukkar opp og forsvinn i løpet av sekund, er eit anna dyr enn eit par der begge lever i timar.

Sorter lista etter opprettingstid før du dreg ein konklusjon. Naboskap i utdataa tyder ingenting, og ei tabellvising inviterer nettopp til den feilen.

Avgjer kva overlapping du ser på

IKEv2-rekey og make-before-break-reautentisering skapar med vilje ei kort overlapping, ved å etablere den nye assosiasjonen før den gamle blir sletta. Tidsstempel avgjer saka, fordi ein gammal SA som forsvinn eit sekund eller to etter at den nye dukkar opp, er fornying som gjer jobben sin. Uavhengige grensesnitttunnelar ser aldri slik ut, sidan kvar av dei varer så lenge grensesnittet er oppe, og sletting av den eine følgjer ikkje av opprettinga av den andre.

Apples administrerte Always On-åtferd er per grensesnitt, og difor kan ei overvaka eining med rette sjå travlare ut enn ein profil som er sett opp manuelt. Ein leverandørapps auto-tilkoplingsbrytar tyder ikkje det same, og ein vanleg on-demand-regel gjer heller ikkje det. Apples oversyn over utrulling skildrar modellen per grensesnitt; samanlikn dei to radene dine med han før du reknar med ei løkke. Begge formene hentar også frå den same tenarpoolen, så overlappinga er det einaste tidlege signalet ditt.

Sjå kvifor éi virtuell adresse for to tunnelar øydelegg svar

Eit svar til telefonen blir adressert til den indre adressa, og kjernen vel ein utgåande tunnel etter destinasjon og policy, ikkje etter grensesnittet telefonen brukte. To samtidige assosiasjonar som held same virtuelle IP med samanfallande policyar, lèt rutingsavgjerda stå utan ein måte å seie kva økt eit svar høyrer til. Nokre svar tek feil tunnel, og telefonen viser ei tilkopling som verkar éin veg eller døyr når Wi-Fi kjem opp. To kommando-utdata provar tilstanden: swanctl --list-sas viser same virtuelle IP på begge SA-ane, og ip xfrm policy viser to identiske veljarar.

Nettopp det paret med utdata legg du i endringsnotatet. Ingen av dei er overtydande åleine, fordi kvar av dei kan sjå plausibel ut for seg sjølv.

Dette er adressering og policy på tenarsida, ikkje feil åtferd frå telefonen, og ingen klientinnstilling skil to identiske indre adresser. Poolen delte ut same verdi to gonger, og policyinstallasjonen godtok han. Les resultatet frå tenarsida før du klandrar klienten.

Endre poolen eller samtidigheitsmodellen, ikkje rekey-timaren

I swanctl-konfigurasjon er unikskap ein uttrykkeleg policy på tilkoplinga: unique = replace fjernar ei eldre tilkopling når ei ny blir etablert, og unique = keep avviser den nye. Begge verdiane verkar når ei tilkopling blir sett opp, ikkje på underassosiasjonane inne i ho.

connections {
  ios-alwayson {
    unique = replace
  }
}

Ingen av verdiane er nøytrale for ein klient per grensesnitt. keep gjenopprettar ein ryddig statusskjerm ved å avvise den andre tunnelen og bryt det administrerte designet, medan replace riv ned den eldre tunnelen og er det same kompromisset den andre vegen. Viss begge tunnelane verkeleg trengst, må backend-en til poolen gje ut ulike leasar for éin identitet, og lease-nøkkelen må skilje førespurnadene. Ein statisk identitet-til-adresse-tabell vil gjerne returnere same adresse to gonger og attskape det opphavlege problemet med meir konfigurasjon. Sjekk korleis backend-en nøklar leasar før du legg til ein andre statisk mapping.

Test overgangane du faktisk rullar ut

Gå ut av Wi-Fi-rekkjevidda med ei aktiv økt, gå deretter inn att, og kontroller at svar kjem i begge retningar. Gjer det to gonger, fordi den andre overgangen er der ein utdatert policy vanlegvis dukkar opp. Test med ein teneste som svarar på tilkoplinga du opna, og gjer utgangen om att medan tunnelen ber trafikk i staden for å stå stille. Ein telefon som kan sende men ikkje ta imot, ser sunn ut i ein handshake-logg og øydelagd ut i ein nettlesar.

Ein statusskjerm redusert til éi rad er ikkje prov på eit fungerande design, berre prov på at éin tunnel er borte. Begge retningane må verke før ein overgang blir godkjend. Skriv ned det du observerte, saman med dei to utdataa frå overlappingskontrollen, slik at neste ingeniør kan samanlikne i staden for å gjenta turen.