iPhone Always On VPN: to tunneller kan dele én virtuel IP

På en overvåget iPhone med en administreret Always On-profil holder telefonen en tunnel for hvert aktivt IP-interface, så mobilnet og Wi-Fi får hver deres. Serveren viser derefter to IKE-sikkerhedsassociationer for én enhed, ofte med én virtuel adresse til fælles, og den første indskydelse er at kalde det en rekey-løkke og begynde at ændre timere. Den indskydelse er som regel forkert. Gå gennem trinnene nedenfor i den rækkefølge, beviserne vises på serveren, og lad telefonens indstillinger være i fred, indtil serveren fortæller dig, hvilket tilfælde du har.

Begynd med de to rækker, serveren allerede har

List associationerne med swanctl --list-sas og læs fire felter på tværs af begge poster: fjernadressen, den godkendte identitet, den tildelte virtuelle IP og oprettelsestiden. To forskellige ydre adresser med én identitet og én virtuel IP er den form, der startede spørgsmålet, og det er værd at skrive ned, før du ændrer noget. Kontroller derefter de underordnede associationer, der hænger på hver af dem, fordi trafikvælgerne afgør, om et destinationsopslag nogensinde ville kunne skelne de to tunneller. Et par, der dukker op og forsvinder inden for sekunder, er et andet dyr end et par, hvor begge lever i timer.

Sortér listen efter oprettelsestid, før du drager en konklusion. Naboskab i outputtet betyder intet, og en tabelvisning indbyder netop til den fejl.

Afgør, hvilket overlap du ser på

IKEv2-rekey og make-before-break-genautentificering skaber et kort overlap med vilje ved at etablere den nye association, før den gamle slettes. Tidsstempler afgør sagen, fordi en gammel SA, der forsvinder et sekund eller to efter den nye, er fornyelse, der gør sit arbejde. Uafhængige interface-tunneller ser aldrig sådan ud, fordi hver af dem består, så længe dens interface er oppe, og sletning af den ene følger ikke af oprettelsen af den anden.

Apples administrerede Always On-adfærd er pr. interface, og derfor kan en overvåget enhed med rette se travlere ud end en profil, der er sat op manuelt. En udbyderapps auto-connect-kontakt betyder ikke det samme, og en almindelig on-demand-regel gør heller ikke. Apples udrulningsoversigt beskriver modellen pr. interface; sammenlign dine to rækker med den, før du antager en løkke. Begge former trækker også fra den samme serverpool, så overlapet er dit eneste tidlige signal.

Se, hvorfor én virtuel adresse til to tunneller ødelægger svar

Et svar til telefonen adresseres til den indre adresse, og kernen vælger en udgående tunnel efter destination og politik, ikke efter det interface, telefonen brugte. To samtidige associationer, der holder samme virtuelle IP med sammenfaldende politikker, efterlader routingbeslutningen uden en måde at sige, hvilken session et svar hører til. Nogle svar tager den forkerte tunnel, og telefonen viser en forbindelse, der virker én vej eller dør, når Wi-Fi kommer op. To kommandouddata beviser tilstanden: swanctl --list-sas viser samme virtuelle IP på begge SA'er, og ip xfrm policy viser to identiske vælgere.

Netop det par af uddata lægger du i ændringsnotatet. Ingen af dem er overbevisende alene, fordi hver af dem kan se plausibel ud for sig selv.

Det er adressering og politik på serversiden, ikke telefonens fejl, og ingen klientindstilling adskiller to identiske indre adresser. Poolen uddelte samme værdi to gange, og politikinstallatøren accepterede den. Læs resultatet fra serverens side, før du bebrejder klienten.

Skift poolen eller samtidighedsmodellen, ikke rekey-timeren

I swanctl-konfiguration er unikhed en udtrykkelig politik på forbindelsen: unique = replace fjerner en ældre forbindelse, når en ny etableres, og unique = keep afviser den nye. Begge værdier virker, når en forbindelse sættes op, ikke på de underordnede SA'er inde i den.

connections {
  ios-alwayson {
    unique = replace
  }
}

Ingen af værdierne er neutrale for en klient pr. interface. keep genskaber en pæn statusskærm ved at afvise den anden tunnel og bryder det administrerede design, mens replace river den ældre tunnel ned og er det samme kompromis den anden vej. Hvis begge tunneller virkelig er nødvendige, skal poolens backend udstede forskellige leases til én identitet, og dens lease-nøgle skal kunne skelne anmodningerne. En statisk identitet-til-adresse-tabel vil gerne returnere samme adresse to gange og genskabe det oprindelige problem med mere konfiguration. Kontroller, hvordan backenden nøgler leases, før du tilføjer en anden statisk mapping.

Test de overgange, du faktisk udruller

Gå ud af Wi-Fi-rækkevidde med en aktiv session, gå derefter ind igen, og kontroller, at svar ankommer i begge retninger. Gør det to gange, fordi den anden overgang er der, hvor en forældet politik normalt dukker op. Test med en tjeneste, der svarer på den forbindelse, du åbnede, og gentag udgangen, mens tunnellen bærer trafik i stedet for at stå stille. En telefon, der kan sende men ikke modtage, ser sund ud i en handshake-log og i stykker i en browser.

En statusskærm reduceret til én række er ikke bevis på et fungerende design, kun bevis på, at én tunnel er væk. Begge retninger skal virke, før en overgang består. Skriv ned, hvad du observerede, sammen med de to uddata fra overlapkontrollen, så den næste ingeniør kan sammenligne i stedet for at gentage turen.