iPhone Always On VPN: dy tunele mund të ndajnë një IP virtuale

Në një iPhone të mbikëqyrur me profil Always On të menaxhuar, telefoni mban një tunel për çdo ndërfaqe IP aktive, kështu që celulari dhe Wi-Fi marrin secili të vetin. Serveri më pas liston dy shoqata sigurie IKE për një pajisje, shpesh duke ndarë një adresë virtuale, dhe impulsi i parë është ta quash cikël rekey dhe të fillosh të ndryshosh kohëmatësit. Ky impuls zakonisht është i gabuar. Ndjekni hapat më poshtë sipas rendit në të cilin provat shfaqen në server, dhe lërini cilësimet e telefonit të qeta derisa serveri t'ju thotë cilin rast keni.

Filloni me dy rreshtat që serveri tashmë i ka

Listoni shoqatat me swanctl --list-sas dhe lexoni katër fusha në të dy zërat: adresën e largët, identitetin e vërtetuar, IP-në virtuale të caktuar dhe kohën e krijimit. Dy adresa të jashtme të ndryshme me një identitet dhe një IP virtuale janë forma që e nisi këtë pyetje, dhe ia vlen ta shënoni përpara çdo ndryshimi. Më pas kontrolloni shoqatat fëmijë të lidhura me secilën, sepse përzgjedhësit e trafikut vendosin nëse një kërkim destinacioni mund t'i dallojë ndonjëherë dy tunelet. Një çift që shfaqet dhe zhduket brenda sekondave është një kafshë tjetër nga një çift ku të dyja jetojnë me orë.

Para se të nxirrni një përfundim, renditni listën sipas kohës së krijimit. Afërsia në dalje nuk do të thotë asgjë, dhe një listë tabelare fton pikërisht atë gabim.

Vendosni se çfarë mbivendosje po shikoni

Rekey i IKEv2 dhe riautentikimi make-before-break krijojnë qëllimisht një mbivendosje të shkurtër, duke vendosur shoqatën e re përpara se të fshihet e vjetra. Vulat kohore e zgjidhin rastin, sepse një SA e vjetër që zhduket një ose dy sekonda pasi shfaqet e reja është rinovim që bën punën e vet. Tunelet e pavarura sipas ndërfaqes nuk duken kurrë kështu, pasi secili vazhdon sa kohë ndërfaqja e tij është lart, dhe fshirja e njërit nuk rrjedh nga krijimi i tjetrit.

Sjellja e menaxhuar e Always On nga Apple është sipas ndërfaqes, prandaj një pajisje e mbikëqyrur mund të duket legjitimisht më e zënë se një profil i konfiguruar me dorë. Ndërprerësi i lidhjes automatike i një aplikacioni ofruesi nuk nënkupton të njëjtën gjë, dhe as një rregull i zakonshëm on-demand. Përmbledhja e vendosjes së Apple përshkruan modelin sipas ndërfaqes; krahasoni dy rreshtat tuaj me të përpara se të supozoni një cikël. Të dyja format marrin edhe nga i njëjti pishinë serveri, kështu që mbivendosja është sinjali juaj i vetëm i hershëm.

Shihni pse një adresë virtuale për dy tunele i prish përgjigjet

Një përgjigje drejt telefonit adresohet në adresën e brendshme, dhe kerneli zgjedh një tunel dalës sipas destinacionit dhe politikës, jo sipas ndërfaqes që përdori telefoni. Dy shoqata të njëkohshme që mbajnë të njëjtën IP virtuale me politika që përputhen e lënë vendimin e rrugëtimit pa mënyrë për të thënë se cilës sesion i përket një përgjigje. Disa përgjigje marrin tunelin e gabuar, dhe telefoni tregon një lidhje që funksionon në një drejtim ose vdes kur shfaqet Wi-Fi. Dy dalje komandash e provojnë gjendjen: swanctl --list-sas tregon të njëjtën IP virtuale në të dy SA, dhe ip xfrm policy tregon dy përzgjedhës identikë.

Pikërisht ai çift daljesh është ai që ngjitni në regjistrin e ndryshimit. Asnjëri vetëm nuk është bindës, sepse secili mund të duket i besueshëm veçmas.

Ky është adresim dhe politikë në anën e serverit, jo sjellje e gabuar e telefonit, dhe asnjë cilësim klienti nuk i ndan dy adresa të brendshme identike. Pishina e dha të njëjtën vlerë dy herë dhe instaluesi i politikës e pranoi. Lexoni rezultatin nga ana e serverit përpara se të fajësoni klientin.

Ndryshoni pishinën ose modelin e njëkohshmërisë, jo kohëmatësin e rekey

Në konfigurimin swanctl, uniciteti është një politikë e shprehur në lidhje: unique = replace heq një lidhje më të vjetër kur vendoset një e re, dhe unique = keep refuzon të sapoardhurin. Të dyja vlerat veprojnë kur vendoset një lidhje, jo në SA-të fëmijë brenda saj.

connections {
  ios-alwayson {
    unique = replace
  }
}

Asnjëra vlerë nuk është neutrale për një klient sipas ndërfaqes. keep rikthen një ekran statusi të rregullt duke refuzuar tunelin e dytë dhe thyen dizajnin e menaxhuar, ndërsa replace rrëzon tunelin më të vjetër dhe është i njëjti kompromis në drejtimin tjetër. Nëse të dy tunelet nevojiten vërtet, backend-i i pishinës duhet të lëshojë qira të ndryshme për një identitet, dhe çelësi i qirasë duhet t'i dallojë kërkesat. Një tabelë statike identitet-në-adresë do të kthejë me kënaqësi të njëjtën adresë dy herë dhe do ta riprodhojë problemin origjinal me më shumë konfigurim. Kontrolloni se si backend-i i çelëson qiratë përpara se të shtoni një hartë të dytë statike.

Provoni tranzicionet që vërtet i vendosni

Dilni jashtë rrezes së Wi-Fi me një sesion aktiv, pastaj rikthehuni, dhe kontrolloni që përgjigjet mbërrijnë në të dy drejtimet. Bëjeni dy herë, sepse tranzicioni i dytë është vendi ku zakonisht shfaqet një politikë e vjetruar. Provoni me një shërbim që përgjigjet në lidhjen që hapët, dhe përsëritni daljen ndërsa tuneli mban trafik në vend që të rrijë i papunë. Një telefon që mund të dërgojë por jo të marrë duket i shëndetshëm në një regjistër handshake dhe i prishur në një shfletues.

Një ekran statusi i reduktuar në një rresht nuk është provë e një dizajni funksional, vetëm provë se një tunel ka ikur. Të dy drejtimet duhet të funksionojnë përpara se një tranzicion të kalojë. Shkruani atë që vëzhguat, së bashku me dy daljet e kontrollit të mbivendosjes, që inxhinieri i radhës të mund të krahasojë në vend që të përsërisë shëtitjen.