iPhone Always On VPN: dva tunela si lahko delita en virtualni IP

Na nadzorovanem iPhonu z upravljanim profilom Always On telefon drži tunel za vsak aktivni vmesnik IP, zato mobilno omrežje in Wi-Fi dobita vsak svojega. Strežnik nato navede dve varnostni asociaciji IKE za eno napravo, pogosto z deljeno virtualno naslovom, in prvi impulz je to imenovati zanka rekey in začeti spreminjati časovnike. Ta impulz je običajno napačen. Prehodite spodnje korake v vrstnem redu, v katerem se dokazi pojavljajo na strežniku, in pustite nastavitve telefona pri miru, dokler vam strežnik ne pove, kateri primer imate.

Začnite z dvema vrsticama, ki jih strežnik že ima

Naštejte asociacije z swanctl --list-sas in preberite štiri polja v obeh vnosih: oddaljeni naslov, overjeno identiteto, dodeljeni virtualni IP in čas nastanka. Dva različna zunanja naslova z eno identiteto in enim virtualnim IP sta oblika, s katerim se je to vprašanje začelo, in vredno ju je zapisati pred kakršno koli spremembo. Nato preverite podrejene asociacije, pritrjene na vsako od njih, ker izbirniki prometa odločajo, ali bi iskanje cilja kdaj lahko razlikovalo oba tunela. Par, ki se pojavi in izgine v nekaj sekundah, je druga žival kot par, kjer oba živita ure.

Pred sklepanjem razvrstite seznam po času nastanka. Sosedstvo v izpisu ne pomeni ničesar, tabelarični seznam pa vabi prav k tej napaki.

Ugotovite, na katero prekrivanje gledate

Rekey IKEv2 in ponovna overitev make-before-break namerno ustvarita kratko prekrivanje, tako da novo asociacijo vzpostavita, preden se stara izbriše. Časovni žigi odločijo primer, ker je stari SA, ki izgine sekundo ali dve po pojavu novega, obnova, ki opravlja svoje delo. Neodvisni tuneli vmesnikov nikoli ne izgledajo tako, saj vsak vztraja, dokler je njegov vmesnik aktiven, in brisanje enega ne izhaja iz ustvarjanja drugega.

Upravljano vedenje Always On podjetja Apple je po vmesniku, zato je lahko nadzorovana naprava upravičeno videti bolj zasedena kot profil, nastavljen ročno. Stikalo za samodejno povezavo v aplikaciji ponudnika ne pomeni istega, običajno pravilo on-demand pa tudi ne. Pregled uvajanja Apple opisuje model po vmesniku; primerjajte svoji dve vrstici z njim, preden domnevate zanko. Obe obliki črpata tudi iz istega strežniškega bazena, zato je prekrivanje vaš edini zgodnji signal.

Poglejte, zakaj en virtualni naslov za dva tunela lomi odgovore

Odgovor telefonu je naslovljen na notranji naslov, jedro pa izbere odhodni tunel glede na cilj in politiko, ne glede na vmesnik, ki ga je uporabil telefon. Dve sočasni asociaciji z istim virtualnim IP in ujemajočimi se politikami pustita odločitev o usmerjanju brez načina, da bi povedali, kateri seji pripada odgovor. Nekateri odgovori gredo skozi napačen tunel, telefon pa kaže povezavo, ki deluje v eno smer ali umre, ko se pojavi Wi-Fi. Dva izpisa ukazov dokazujeta stanje: swanctl --list-sas kaže isti virtualni IP na obeh SA, ip xfrm policy pa kaže dva enaka izbirnika.

Prav ta par izpisov prilepite v zapis o spremembi. Noben sam po sebi ni prepričljiv, ker je vsak lahko videti verjeten samostojno.

To je naslavljanje in politika na strani strežnika, ne napačno vedenje telefona, in nobena nastavitev odjemalca ne loči dveh enakih notranjih naslovov. Bazen je isto vrednost izdal dvakrat in namestnik pravilnika jo je sprejel. Preberite rezultat s strani strežnika, preden obtožite odjemalca.

Spremenite bazen ali model sočasnosti, ne časovnika rekey

V konfiguraciji swanctl je edinstvenost izrecna politika na povezavi: unique = replace odstrani starejšo povezavo, ko se vzpostavi nova, unique = keep pa novega prišleka zavrne. Obe vrednosti delujeta pri nastavljanju povezave, ne na podrejenih SA v njej.

connections {
  ios-alwayson {
    unique = replace
  }
}

Nobena vrednost ni nevtralna za odjemalca po vmesniku. keep obnovi urejen zaslon stanja tako, da zavrne drugi tunel, in pokvari upravljano zasnovo, medtem ko replace podre starejši tunel in je isti kompromis v drugo smer. Če sta oba tunela res potrebna, mora zaledje bazena izdajati različne zakupnike za eno identiteto, njegov ključ zakupa pa mora razlikovati zahteve. Statična tabela identiteta-na-naslov bo z veseljem vrnila isti naslov dvakrat in ponovila prvotno težavo z več konfiguracije. Preverite, kako zaledje sestavlja ključe zakupa, preden dodate drugo statično preslikavo.

Preizkusite prehode, ki jih res uvajate

Pojdite iz dosega Wi-Fi z aktivno sejo, nato se vrnite in preverite, da odgovori prihajajo v obe smeri. Naredite to dvakrat, ker se pri drugem prehodu običajno pokaže zastarela politika. Preizkusite s storitvijo, ki odgovarja na povezavi, ki ste jo odprli, in ponovite izhod, medtem ko tunel nosi promet, namesto da stoji nedejaven. Telefon, ki zna pošiljati, ne pa prejemati, je videti zdrav v dnevniku rokovanja in pokvarjen v brskalniku.

Zaslon stanja, skrčen na eno vrstico, ni dokaz delujoče zasnove, le dokaz, da je en tunel izginil. Obe smeri morata delovati, preden prehod uspe. Zapišite, kaj ste opazili, skupaj z dvema izpisoma preverjanja prekrivanja, da bo naslednji inženir lahko primerjal, namesto da bi ponavljal sprehod.