iPhone Always On VPN: twee tonnels kan een virtuele IP deel

Op 'n toesig-iPhone met 'n bestuurde Always On-profiel hou die foon 'n tonnel vir elke aktiewe IP-koppelvlak, so selfoon en Wi-Fi kry elkeen sy eie. Die bediener lys dan twee IKE-sekuriteitsassosiasies vir een toestel, dikwels met een virtuele adres gedeel, en die eerste instink is om dit 'n herleutel-lus te noem en timers te begin verander. Daardie instink is gewoonlik verkeerd. Werk deur die stappe hieronder in die volgorde waarin die bewyse op die bediener verskyn, en los die foon se instellings alleen totdat die bediener vir jou sê watter geval jy het.

Begin met die twee rye wat die bediener reeds het

Lys die assosiasies met swanctl --list-sas en lees vier velde oor albei inskrywings: die afstandadres, die geauthentiseerde identiteit, die toegewysde virtuele IP en die skeppingstyd. Twee verskillende buitenste adresse met een identiteit en een virtuele IP is die vorm wat hierdie vraag begin het, en dit is die moeite werd om dit voor enige verandering neer te skryf. Kyk dan na die kindassosiasies wat aan elkeen gekoppel is, want die verkeerskeerders besluit of 'n bestemmingsopsoek ooit die twee tonnels uitmekaar kon hou. 'n Paar wat binne sekondes verskyn en verdwyn, is 'n ander dier as 'n paar wat albei ure lank leef.

Sorteer die lys volgens skeppingstyd voordat jy 'n gevolgtrekking maak. Nabyskap in die uitset beteken niks, en 'n tabellys nooi presies daardie fout uit.

Bepaal watter oorvleueling jy sien

IKEv2-herleuteling en make-before-break-herverifikasie skep doelbewus 'n kort oorvleueling, deur die nuwe assosiasie te vestig voordat die ou een geskrap word. Tydstempels beslis die saak, want 'n ou SA wat 'n sekonde of twee ná die nuwe een verdwyn, is vernuwing wat sy werk doen. Onafhanklike koppelvlak-tonnels lyk nooit so nie, want elkeen bly voortbestaan terwyl sy koppelvlak op is, en die skrapping van die een volg nie uit die skepping van die ander nie.

Apple se bestuurde Always On-gedrag is per koppelvlak, en daarom kan 'n toesigtoestel wettig besiger lyk as 'n handmatig opgestelde profiel. 'n Verskafferapp se outo-verbind-skakelaar impliseer nie dieselfde nie, en 'n gewone on-demand-reël ook nie. Die Apple-ontplooiingsoorsig beskryf die per-koppelvlak-model; vergelyk jou twee rye daarmee voordat jy 'n lus aanneem. Albei vorms tap ook uit dieselfde bedienerpoel, so die oorvleueling is jou enigste vroeë sein.

Sien waarom een virtuele adres vir twee tonnels antwoorde breek

'n Antwoord aan die foon word na die binne-adres geadresseer, en die kernel kies 'n uitgaande tonnel volgens bestemming en beleid, nie volgens die koppelvlak wat die foon gebruik het nie. Twee gelyktydige assosiasies met dieselfde virtuele IP en ooreenstemmende beleide laat die roetebesluit met geen manier om te sê by watter sessie 'n antwoord hoort nie. Sommige antwoorde neem die verkeerde tonnel, en die foon wys 'n verbinding wat een rigting werk of sterf wanneer Wi-Fi opkom. Twee opdragte se uitsette bewys die toestand: swanctl --list-sas wat dieselfde virtuele IP op albei SA's wys, en ip xfrm policy wat twee identiese keerders wys.

Daardie paar uitsette is ook wat jy in die veranderingsrekord plak. Nie een alleen is oortuigend nie, want elkeen kan op sy eie geloofwaardig lyk.

Dit is bedienerkant-adressering en -beleid, nie foon-wangedrag nie, en geen kliëntinstelling skei twee identiese binne-adresse nie. Die poel het dieselfde waarde twee keer uitgegee en die beleidsinstalleerder het dit aanvaar. Lees die resultaat van die bediener se kant voordat jy die kliënt blameer.

Verander die poel of die gelyktydigheidsmodel, nie die herleutel-timer nie

In swanctl-konfigurasie is uniekheid 'n eksplisiete beleid op die verbinding: unique = replace verwyder 'n ouer verbinding wanneer 'n nuwe een vestig, en unique = keep verwerp die nuweling. Albei waardes tree op wanneer 'n verbinding opgestel word, nie op die kind-SA's daarin nie.

connections {
  ios-alwayson {
    unique = replace
  }
}

Nie een waarde is neutraal vir 'n per-koppelvlak-kliënt nie. keep herstel 'n netjiese statusskerm deur die tweede tonnel te weier en breek die bestuurde ontwerp, terwyl replace die ouer tonnel afbreek en dieselfde kompromie in die ander rigting is. As albei tonnels werklik nodig is, moet die poel-agterkant afsonderlike leases vir een identiteit uitreik, en sy lease-sleutel moet die versoeke onderskei. 'n Statiese identiteit-tot-adres-tabel sal met graagte dieselfde adres twee keer teruggee en die oorspronklike probleem met meer konfigurasie herproduseer. Kyk hoe die agterkant leases sleutel voordat jy 'n tweede statiese kartering byvoeg.

Toets die oorgange wat jy werklik uitrol

Stap uit Wi-Fi-bereik met 'n aktiewe sessie, stap dan terug in, en kyk dat antwoorde in albei rigtings aankom. Doen dit twee keer, want die tweede oorgang is waar 'n verouderde beleid gewoonlik opduik. Toets met 'n diens wat antwoord op die verbinding wat jy geopen het, en herhaal die uitstap terwyl die tonnel verkeer dra eerder as om ledig te sit. 'n Foon wat kan stuur maar nie ontvang nie, lyk gesond in 'n handskudlog en stukkend in 'n blaaier.

'n Statuskerm wat tot een ry verminder is, is nie bewyse van 'n werkende ontwerp nie, net bewyse dat een tonnel weg is. Albei rigtings moet werk voordat 'n oorgang slaag. Skryf neer wat jy waargeneem het, saam met die twee uitsette van die oorvleuelingstoets, sodat die volgende ingenieur kan vergelyk in plaas van die wandeling te herhaal.