iPhone Always On VPN: kaks tunnelit võivad jagada üht virtuaalset IP-d

Järelevalvealuses iPhone'is haldatud Always On profiiliga hoiab telefon iga aktiivse IP-liidese jaoks tunnelit, nii et mobiilside ja Wi-Fi saavad kumbki omad. Seejärel loetleb server ühe seadme jaoks kaks IKE turvaassotsiatsiooni, sageli jagades üht virtuaalset aadressi, ja esimene tung on nimetada seda võtmeuuenduse tsükliks ja hakata taimereid muutma. See tung on tavaliselt vale. Käige allolevad sammud läbi selles järjekorras, milles tõendid serveris ilmuvad, ja jätke telefoni seaded rahule, kuni server ütleb, milline juhtum teil on.

Alustage kahest reast, mis serveril juba on

Loetlege assotsiatsioonid käsuga swanctl --list-sas ja lugege mõlemas kirjes nelja välja: kaugkohaserveri aadress, autenditud identiteet, määratud virtuaalne IP ja loomise aeg. Kaks erinevat välist aadressi ühe identiteedi ja ühe virtuaalse IP-ga on kuju, mis selle küsimuse algatas, ja see tasub enne igasugust muudatust kirja panna. Seejärel kontrollige kummagi küljes olevaid tütarassotsiatsioone, sest liiklusvalijad otsustavad, kas sihtkoha otsing suudaks neid kahte tunnelit üldse eristada. Paar, mis ilmub ja kaob sekundite jooksul, on teine loom kui paar, mis mõlemad elavad tunde.

Enne järelduse tegemist sorteerige loend loomisaja järgi. Kõrvuti paiknemine väljundis ei tähenda midagi ja tabelikujuline loend kutsub just sellele veale.

Otsustage, millist kattumist te vaatate

IKEv2 võtmeuuendus ja make-before-break uuesti autentimine loovad meelega lühikese kattumise, luues uue assotsiatsiooni enne vana kustutamist. Ajatemplid otsustavad juhtumi, sest vana SA, mis kaob sekund või kaks pärast uue ilmumist, on uuendus, mis teeb oma tööd. Sõltumatud liidesetunnelid ei näe kunagi sellised välja, sest igaüks püsib seni, kui selle liides on üleval, ja ühe kustutamine ei tulene teise loomisest.

Apple'i hallatud Always On käitumine on liidesepõhine, mistõttu järelevalvealune seade võib õigustatult tunduda hõivatum kui käsitsi seadistatud profiil. Teenusepakkuja rakenduse automaatse ühenduse lüliti ei tähenda sama, ja tavaline on-demand reegel samuti mitte. Apple'i juurutamise ülevaade kirjeldab liidesepõhist mudelit; võrrelge oma kahte rida sellega enne tsükli eeldamist. Mõlemad kujud ammutavad ka samast serveripõhisest varust, seega on kattumine teie ainus varajane signaal.

Vaadake, miks üks virtuaalne aadress kahe tunneli jaoks vastused rikub

Telefonile saadetud vastus adresseeritakse sisemisele aadressile ja kernel valib väljuva tunneli sihtkoha ja poliitika järgi, mitte selle liidese järgi, mida telefon kasutas. Kaks samaaegset assotsiatsiooni, mis hoiavad sama virtuaalset IP-d kattuvate poliitikatega, jätavad marsruutimisotsuse ilma viisita öelda, millisesse seanssi vastus kuulub. Mõned vastused lähevad vale tunnelisse ja telefon näitab ühendust, mis töötab ühes suunas või sureb, kui Wi-Fi tõuseb. Kaks käsuväljundit tõestavad olekut: swanctl --list-sas näitab sama virtuaalset IP-d mõlemas SA-s ja ip xfrm policy näitab kahte identset valijat.

Just selle väljundipaari kleepite muudatuste kirjesse. Kumbki üksi ei ole veenev, sest kumbki võib eraldi usutavana tunduda.

See on serveripoolne adresseerimine ja poliitika, mitte telefoni väärkäitumine, ja ükski kliendiseade ei erista kahte identset sisemist aadressi. Varu andis sama väärtuse kaks korda välja ja poliitika paigaldaja võttis selle vastu. Lugege tulemust serveri poolelt enne, kui klienti süüdistate.

Muutke varu või samaaegsuse mudelit, mitte võtmeuuenduse taimerit

swanctl konfiguratsioonis on ainulaadsus ühendusel selgesõnaline poliitika: unique = replace eemaldab vanema ühenduse, kui uus luuakse, ja unique = keep lükkab uustulnuka tagasi. Mõlemad väärtused mõjuvad ühenduse seadistamisel, mitte selle sees olevatele tütar-SA-dele.

connections {
  ios-alwayson {
    unique = replace
  }
}

Kumbki väärtus ei ole liidesepõhise kliendi jaoks neutraalne. keep taastab korrastatud olekuekraani, keeldudes teisest tunnelist, ja rikub hallatud disaini, samas kui replace rebib vanema tunneli maha ja on sama kompromiss vastassuunas. Kui mõlemat tunnelit on tõesti vaja, peab varu taustsüsteem ühe identiteedi jaoks väljastama erinevad liisingud ja selle liisinguvõti peab päringuid eristama. Staatiline identiteedi-aadressi tabel tagastab hea meelega sama aadressi kaks korda ja taastoodab algse probleemi suurema konfiguratsiooniga. Kontrollige, kuidas taustsüsteem liisinguid võtmetab, enne teise staatilise vastenduse lisamist.

Testige üleminekuid, mida te tegelikult juurutate

Minge aktiivse seansiga Wi-Fi levialast välja, tulge siis tagasi ja kontrollige, et vastused saabuvad mõlemas suunas. Tehke seda kaks korda, sest teine üleminek on koht, kus aegunud poliitika tavaliselt ilmub. Testige teenusega, mis vastab teie avatud ühendusel, ja korrake väljaminekut, kui tunnel kannab liiklust, mitte ei seisa tühjalt. Telefon, mis suudab saata, kuid mitte vastu võtta, näeb käepigistuse logis terve ja brauseris katki välja.

Ühele reale taandatud olekuekraan ei ole tõestus toimivast disainist, vaid ainult tõestus, et üks tunnel on kadunud. Mõlemad suunad peavad töötama, enne kui üleminek läbib. Kirjutage üles, mida täheldasite, koos kattumise kontrolli kahe väljundiga, et järgmine insener saaks võrrelda, mitte jalutuskäiku korrata.