iPhone Always On VPN: twa tunnels kinne ien firtuele IP diele

Always On-tunnels per ynterface binne gjin mislearre rekey. Ferlykje de twa SA's op de tsjinner, en beslút dan oft ien identiteit twa ynterne adressen hâlde mei.

Op in bewarre iPhone mei in beheard Always On-profyl hâldt de telefoan in tunnel foar elke aktive IP-ynterface, sadat selulêr en Wi-Fi elk har eigen krije. De tsjinner listet dan twa IKE-feiligensassosjaasjes foar ien apparaat, faak mei ien firtueel adres dield, en de earste ympuls is om it in rekey-lus te neamen en timers te feroarjen. Dy ympuls is meastentiids ferkeard. Wurkje de stappen hjirûnder ôf yn 'e folchoarder wêryn't de bewiisstikken op 'e tsjinner ferskine, en lit de ynstellings fan 'e telefoan gewurde oant de tsjinner seit hokker gefal jo hawwe.

Begjin mei de twa rigen dy't de tsjinner al hat

List de assosjaasjes mei swanctl --list-sas en lês fjouwer fjilden oer beide ynfieringen: it fiere adres, de autentisearre identiteit, de tawiisde firtuele IP en de oanmaktiid. Twa ferskillende bûtenadressen mei ien identiteit en ien firtuele IP is de foarm dy't dizze fraach begon, en it is de muoite wurdich om dy foar elke feroaring op te skriuwen. Kontrolearje dan de bernassosjaasjes oan elk fan har, want de ferkearsselektearders beslute oft in bestimmingsoersyk de twa tunnels ea útinoar hâlde koe. In pear dat binnen sekonden ferskynt en ferdwynt is in oar bist as in pear dat beide oeren libbet.

Sortearje de list op oanmaktiid foardat jo in konklúzje lûke. Neistlizzens yn 'e útfier betsjut neat, en in tabelêre list noeget krekt ta dy flater út.

Beslúts hokker oerlaping jo sjogge

IKEv2-rekey en make-before-break-werautentikaasje meitsje mei opsetsin in koarte oerlaping, troch de nije assosjaasje te festigjen foardat de âlde wiske wurdt. Tiidstimpels besljochtsje de saak, want in âlde SA dy't in sekonde of twa ferdwynt nei't de nije ferskynt, is fernijing dy't syn wurk docht. Unôfhinklike ynterface-tunnels sjogge der nea sa út, want elk bliuwt bestean salang't syn ynterface omheech is, en it wiskjen fan 'e iene folget net út it meitsjen fan 'e oare.

Apple syn beheard Always On-gedrach is per ynterface, dêrom kin in bewarre apparaat legitimaasje drokker lykje as in mei de hân ynsteld profyl. De autofrêstingsknop fan in provider-app betsjut net itselde, en in gewoane on-demand-regel ek net. It Apple-útrôloersjoch beskriuwt it model per ynterface; ferlykje jo twa rigen dêrmei foardat jo in lus oannimme. Beide foarmen helje ek út deselde tsjinnerpool, dus de oerlaping is jo iennichste iere sinjaal.

Sjoch wêrom't ien firtueel adres foar twa tunnels antwurden brekt

In antwurd oan 'e telefoan wurdt adressearre oan it ynterne adres, en de kearn kiest in útgongstunnel op bestimming en belied, net op 'e ynterface dy't de telefoan brûkte. Twa tagelyk assosjaasjes mei deselde firtuele IP en oerienkommende beliedsregels litte de routingbeslissing sûnder manier om te sizzen by hokker sesje in antwurd heart. Guon antwurden nimme de ferkearde tunnel, en de telefoan toant in ferbining dy't ien kant op wurket of stjert as Wi-Fi omheech komt. Twa komando-útfieringen bewize de tastân: swanctl --list-sas lit deselde firtuele IP op beide SA's sjen, en ip xfrm policy lit twa identike selektearders sjen.

Krekt dat pear útfieringen plakke jo yn it feroaringsrekord. Gjin fan beide is allinnich oertsjûgjend, want elk kin op himsels leauwensweardich lykje.

Dit is adressearjen en belied oan 'e tsjinnerkant, gjin misdraging fan 'e telefoan, en gjin klantynstelling skiedt twa identike ynterne adressen. De pool joech deselde wearde twa kear út en de beliedsynstallearder akseptearre it. Lês it resultaat fan 'e tsjinnerkant foardat jo de klant de skuld jouwe.

Feroarje de pool of it njonkenheidsmodel, net de rekey-timer

Yn swanctl-konfiguraasje is unykheid in eksplisyt belied op 'e ferbining: unique = replace ferwideret in âldere ferbining as in nije him festiget, en unique = keep wiist de nijkommer ôf. Beide wearden wurkje as in ferbining oprjochte wurdt, net op 'e bern-SA's deryn.

connections {
  ios-alwayson {
    unique = replace
  }
}

Gjin fan beide wearden is neutraal foar in per-ynterface-klant. keep herstelt in kreaze statuskaai troch de twadde tunnel te wegerjen en brekt it behearde ûntwerp, wylst replace de âldere tunnel delhellet en deselde kompromis de oare kant op is. As beide tunnels wier nedich binne, moat de pool-backend foar ien identiteit ferskate leases útjaan, en syn lease-kaai moat de oanfregings ûnderskiede. In statyske identiteit-nei-adres-tabel sil grif twa kear itselde adres weromjaan en it oarspronklike probleem mei mear konfiguraasje reprodusearje. Kontrolearje hoe't de backend leases kaaiet foardat jo in twadde statyske mapping tafoegje.

Test de oergongen dy't jo echt útrolle

Kuiersje út it Wi-Fi-berik mei in aktive sesje, kuiersje dan werom, en kontrolearje dat antwurden yn beide rjochtingen oankomme. Doch it twa kear, want de twadde oergong is wêr't in ferâldere belied meastentiids opkomt. Test mei in tsjinst dy't antwurdet op 'e ferbining dy't jo iepene hawwe, en werhelje it útgong wylst de tunnel ferkear draacht ynstee fan stil te stean. In telefoan dy't stjoere kin mar net ûntfange, liket sûn yn in handshake-log en stikken yn in browser.

In statuskaai werombrocht ta ien rige is gjin bewiis fan in wurkjend ûntwerp, allinne bewiis dat ien tunnel fuort is. Beide rjochtingen moatte wurkje foardat in oergong slagget. Skriuw op wat jo waarnommen hawwe, tegearre mei de twa útfieringen fan 'e oerlapingskontrôle, sadat de folgjende yngenieur ferlykje kin ynstee fan 'e kuiertocht te werheljen.

Relatearre artikelen