iPhone Always On VPN: to tunneler kan dele én virtuell IP

På en overvåket iPhone med en administrert Always On-profil holder telefonen en tunnel for hvert aktive IP-grensesnitt, slik at mobilnett og Wi-Fi får hver sin. Serveren viser deretter to IKE-sikkerhetsassosiasjoner for én enhet, ofte med én virtuell adresse til felles, og den første innskytelsen er å kalle det en rekey-løkke og begynne å endre timere. Den innskytelsen er som regel feil. Gå gjennom trinnene nedenfor i den rekkefølgen bevisene dukker opp på serveren, og la telefonens innstillinger være i fred til serveren forteller deg hvilket tilfelle du har.

Begynn med de to radene serveren allerede har

List assosiasjonene med swanctl --list-sas og les fire felt på tvers av begge oppføringene: fjernadressen, den autentiserte identiteten, den tildelte virtuelle IP-en og opprettelsestiden. To forskjellige ytre adresser med én identitet og én virtuell IP er formen som startet dette spørsmålet, og det er verdt å skrive den ned før noen endring. Sjekk deretter underassosiasjonene som henger på hver av dem, fordi trafikkvelgerne avgjør om et destinasjonsoppslag noen gang kunne skille de to tunnelene. Et par som dukker opp og forsvinner i løpet av sekunder, er et annet dyr enn et par der begge lever i timer.

Sorter listen etter opprettelsestid før du trekker en konklusjon. Naboskap i utdataene betyr ingenting, og en tabellvisning inviterer nettopp til den feilen.

Avgjør hvilken overlapping du ser på

IKEv2-rekey og make-before-break-reautentisering skaper med vilje en kort overlapping, ved å etablere den nye assosiasjonen før den gamle slettes. Tidsstempler avgjør saken, fordi en gammel SA som forsvinner et sekund eller to etter at den nye dukker opp, er fornyelse som gjør jobben sin. Uavhengige grensesnitttunneler ser aldri slik ut, siden hver av dem består så lenge grensesnittet er oppe, og sletting av den ene følger ikke av opprettelsen av den andre.

Apples administrerte Always On-atferd er per grensesnitt, og derfor kan en overvåket enhet med rette se travlere ut enn en profil som er satt opp manuelt. En leverandørapps auto-tilkoblingsbryter betyr ikke det samme, og en vanlig on-demand-regel gjør heller ikke det. Apples oversikt over utrulling beskriver modellen per grensesnitt; sammenlign de to radene dine med den før du antar en løkke. Begge formene henter også fra den samme serverpoolen, så overlappingen er ditt eneste tidlige signal.

Se hvorfor én virtuell adresse for to tunneler ødelegger svar

Et svar til telefonen adresseres til den indre adressen, og kjernen velger en utgående tunnel etter destinasjon og policy, ikke etter grensesnittet telefonen brukte. To samtidige assosiasjoner som holder samme virtuelle IP med sammenfallende policyer, lar rutingsbeslutningen stå uten en måte å si hvilken økt et svar hører til. Noen svar tar feil tunnel, og telefonen viser en forbindelse som virker én vei eller dør når Wi-Fi kommer opp. To kommando-utdata beviser tilstanden: swanctl --list-sas viser samme virtuelle IP på begge SA-ene, og ip xfrm policy viser to identiske velgere.

Nettopp det paret med utdata legger du i endringsnotatet. Ingen av dem er overbevisende alene, fordi hver av dem kan se plausibel ut for seg selv.

Dette er adressering og policy på serversiden, ikke feil oppførsel fra telefonen, og ingen klientinnstilling skiller to identiske indre adresser. Poolen delte ut samme verdi to ganger, og policyinstallasjonen godtok den. Les resultatet fra serversiden før du klandrer klienten.

Endre poolen eller samtidighetsmodellen, ikke rekey-timeren

I swanctl-konfigurasjon er unikhet en uttrykkelig policy på forbindelsen: unique = replace fjerner en eldre forbindelse når en ny etableres, og unique = keep avviser den nye. Begge verdiene virker når en forbindelse settes opp, ikke på underassosiasjonene inne i den.

connections {
  ios-alwayson {
    unique = replace
  }
}

Ingen av verdiene er nøytrale for en klient per grensesnitt. keep gjenoppretter en ryddig statusskjerm ved å avvise den andre tunnelen og bryter det administrerte designet, mens replace river ned den eldre tunnelen og er det samme kompromisset den andre veien. Hvis begge tunnelene virkelig trengs, må poolens backend utstede forskjellige leases for én identitet, og lease-nøkkelen må skille forespørslene. En statisk identitet-til-adresse-tabell vil gjerne returnere samme adresse to ganger og gjenskape det opprinnelige problemet med mer konfigurasjon. Sjekk hvordan backenden nøkler leases før du legger til en andre statisk mapping.

Test overgangene du faktisk ruller ut

Gå ut av Wi-Fi-rekkevidden med en aktiv økt, gå deretter inn igjen, og kontroller at svar ankommer i begge retninger. Gjør det to ganger, fordi den andre overgangen er der en utdatert policy vanligvis dukker opp. Test med en tjeneste som svarer på forbindelsen du åpnet, og gjenta utgangen mens tunnelen bærer trafikk i stedet for å stå stille. En telefon som kan sende men ikke motta, ser sunn ut i en handshake-logg og ødelagt ut i en nettleser.

En statusskjerm redusert til én rad er ikke bevis på et fungerende design, bare bevis på at én tunnel er borte. Begge retninger må virke før en overgang består. Skriv ned det du observerte, sammen med de to utdataene fra overlappingskontrollen, slik at neste ingeniør kan sammenligne i stedet for å gjenta turen.