iPhone Always On VPN: du tuneliai gali dalytis vienu virtualiuoju IP

Prižiūrimame iPhone su valdomu Always On profiliu telefonas laiko tunelį kiekvienai aktyviai IP sąsajai, todėl mobilusis ryšys ir Wi-Fi gauna po savąjį. Tada serveris vienam įrenginiui išvardija dvi IKE saugos asociacijas, dažnai bendrai naudodamas vieną virtualųjį adresą, ir pirmas impulsas yra pavadinti tai rekey kilpa ir pradėti keisti laikmačius. Tas impulsas paprastai klaidingas. Pereikite toliau pateiktus veiksmus ta tvarka, kuria įrodymai atsiranda serveryje, ir palikite telefono nustatymus ramybėje, kol serveris nepasakys, kuris atvejis jūsų.

Pradėkite nuo tų dviejų eilučių, kurias serveris jau turi

Išvardykite asociacijas su swanctl --list-sas ir perskaitykite keturis laukus abiejuose įrašuose: nuotolinį adresą, autentifikuotą tapatybę, priskirtą virtualųjį IP ir sukūrimo laiką. Du skirtingi išoriniai adresai su viena tapatybe ir vienu virtualiuoju IP yra forma, kuri pradėjo šį klausimą, ir verta ją užsirašyti prieš bet kokį pakeitimą. Tada patikrinkite prie kiekvienos prijungtas antrines asociacijas, nes srauto selektoriai nusprendžia, ar paskirties vietos paieška kada nors galėtų atskirti du tunelius. Pora, kuri per sekundes pasirodo ir dingsta, yra kitas gyvūnas nei pora, kuri abi gyvena valandas.

Prieš darydami išvadą, surikiuokite sąrašą pagal sukūrimo laiką. Gretimumas išvestyje nieko nereiškia, o lentelės formos sąrašas kaip tik kviečia šią klaidą.

Nuspręskite, į kokį persidengimą žiūrite

IKEv2 rekey ir make-before-break pakartotinė autentifikacija sąmoningai sukuria trumpą persidengimą, nustatydami naują asociaciją prieš ištrindami senąją. Laiko žymos išsprendžia atvejį, nes senas SA, kuris dingsta sekundę ar dvi po naujojo pasirodymo, yra atnaujinimas, atliekantis savo darbą. Nepriklausomi sąsajų tuneliai niekada taip neatrodo, nes kiekvienas išlieka, kol jo sąsaja veikia, o vieno ištrynimas nekyla iš kito sukūrimo.

Apple valdomas Always On elgesys yra pagal sąsają, todėl prižiūrimas įrenginys gali teisėtai atrodyti užimtesnis nei rankiniu būdu sukonfigūruotas profilis. Tiekėjo programėlės automatinio prisijungimo jungiklis nereiškia to paties, o įprasta on-demand taisyklė taip pat ne. Apple diegimo apžvalga aprašo modelį pagal sąsają; palyginkite savo dvi eilutes su ja prieš manydami, kad tai kilpa. Abi formos taip pat semiasi iš to paties serverio telkinio, todėl persidengimas yra vienintelis ankstyvas signalas.

Pažiūrėkite, kodėl vienas virtualusis adresas dviem tuneliams sugadina atsakymus

Atsakymas telefonui adresuojamas vidiniam adresui, o branduolys išeinantį tunelį renkasi pagal paskirties vietą ir politiką, o ne pagal sąsają, kurią naudojo telefonas. Dvi vienalaikės asociacijos, turinčios tą patį virtualųjį IP ir sutampančias politikas, palieka maršrutizavimo sprendimą be būdo pasakyti, kuriai sesijai priklauso atsakymas. Kai kurie atsakymai patenka į netinkamą tunelį, o telefonas rodo ryšį, kuris veikia viena kryptimi arba miršta, kai pakyla Wi-Fi. Du komandų išvedimai įrodo būseną: swanctl --list-sas rodo tą patį virtualųjį IP abiejuose SA, o ip xfrm policy rodo du identiškus selektorius.

Būtent šią išvedimų porą įklijuojate į pakeitimų žurnalą. Nė vienas atskirai neįtikinantis, nes kiekvienas atskirai gali atrodyti tikėtinas.

Tai serverio pusės adresavimas ir politika, o ne netinkamas telefono elgesys, ir joks kliento nustatymas neatskiria dviejų identiškų vidinių adresų. Telkinys du kartus išdavė tą pačią reikšmę, o politikos diegėjas ją priėmė. Perskaitykite rezultatą iš serverio pusės, prieš kaltindami klientą.

Keiskite telkinį arba lygiagretumo modelį, o ne rekey laikmatį

swanctl konfigūracijoje unikalumas yra aiški politika ryšiui: unique = replace pašalina senesnį ryšį, kai nustatomas naujas, o unique = keep atmeta naujoką. Abi reikšmės veikia nustatant ryšį, o ne jo viduje esančius antrinius SA.

connections {
  ios-alwayson {
    unique = replace
  }
}

Nė viena reikšmė nėra neutrali klientui pagal sąsają. keep atkuria tvarkingą būsenos ekraną atmesdamas antrą tunelį ir sugriauna valdomą dizainą, o replace numeta senesnį tunelį ir yra tas pats kompromisas priešinga kryptimi. Jei abiejų tunelių tikrai reikia, telkinio backend turi išduoti skirtingas nuomas vienai tapatybei, o jo nuomos raktas turi atskirti užklausas. Statinė tapatybės-ir-adreso lentelė mielai grąžins tą patį adresą du kartus ir atkartos pradinę problemą su daugiau konfigūracijos. Patikrinkite, kaip backend sudaro nuomų raktus, prieš pridėdami antrą statinį susiejimą.

Išbandykite perėjimus, kuriuos tikrai diegiate

Išeikite iš Wi-Fi diapazono su aktyvia sesija, tada grįžkite, ir patikrinkite, kad atsakymai ateina abiem kryptimis. Padarykite tai du kartus, nes antras perėjimas yra vieta, kur paprastai pasirodo pasenusi politika. Išbandykite su paslauga, kuri atsako jūsų atidarytame ryšyje, ir pakartokite išėjimą, kai tunelis neša srautą, o ne stovi nenaudojamas. Telefonas, kuris gali siųsti, bet negali priimti, atrodo sveikas rankos paspaudimo žurnale ir sugedęs naršyklėje.

Būsenos ekranas, sutrauktas į vieną eilutę, nėra veikiančio dizaino įrodymas, tik įrodymas, kad vienas tunelis dingo. Abi kryptys turi veikti, kol perėjimas praeina. Užsirašykite, ką pastebėjote, kartu su dviem persidengimo patikros išvedimais, kad kitas inžinierius galėtų palyginti, o ne kartoti pasivaikščiojimą.