iPhone Always On VPN: două tuneluri pot împărți un IP virtual

Pe un iPhone supravegheat cu un profil Always On administrat, telefonul ține un tunel pentru fiecare interfață IP activă, așa că celular și Wi-Fi primesc fiecare al său. Serverul listează apoi două asocieri de securitate IKE pentru un singur dispozitiv, adesea partajând o adresă virtuală, iar primul instinct este să numești asta buclă de rekey și să începi să schimbi temporizatoare. Acel instinct este de obicei greșit. Parcurgeți pașii de mai jos în ordinea în care dovezile apar pe server și lăsați setările telefonului în pace până când serverul vă spune ce caz aveți.

Începeți cu cele două rânduri pe care serverul le are deja

Listați asocierile cu swanctl --list-sas și citiți patru câmpuri în ambele intrări: adresa la distanță, identitatea autentificată, IP-ul virtual atribuit și momentul creării. Două adrese externe diferite cu o identitate și un IP virtual sunt forma care a pornit această întrebare, și merită notată înainte de orice modificare. Apoi verificați asocierile copil atașate fiecăreia, pentru că selectorii de trafic decid dacă o căutare de destinație ar putea vreodată distinge cele două tuneluri. O pereche care apare și dispare în câteva secunde este un alt animal decât o pereche în care ambele trăiesc ore întregi.

Sortați lista după momentul creării înainte de a trage o concluzie. Vecinătatea în ieșire nu înseamnă nimic, iar o listare tabelară invită exact la acea greșeală.

Decideți la ce suprapunere vă uitați

Rekey-ul IKEv2 și reautentificarea make-before-break creează intenționat o suprapunere scurtă, stabilind noua asociere înainte de a o șterge pe cea veche. Marcajele de timp rezolvă cazul, pentru că un SA vechi care dispare o secundă sau două după ce apare cel nou este reînnoire care își face treaba. Tunelurile independente pe interfață nu arată niciodată așa, fiindcă fiecare persistă cât timp interfața lui este activă, iar ștergerea unuia nu decurge din crearea celuilalt.

Comportamentul Always On administrat al Apple este pe interfață, de aceea un dispozitiv supravegheat poate părea în mod legitim mai ocupat decât un profil configurat manual. Comutatorul de conectare automată al unei aplicații de furnizor nu implică același lucru, iar o regulă on-demand obișnuită nici atât. Prezentarea generală a implementării Apple descrie modelul pe interfață; comparați cele două rânduri ale dvs. cu ea înainte de a presupune o buclă. Ambele forme se alimentează și din același bazin al serverului, așa că suprapunerea este singurul dvs. semnal timpuriu.

Vedeți de ce o singură adresă virtuală pentru două tuneluri strică răspunsurile

Un răspuns către telefon este adresat adresei interne, iar nucleul alege un tunel de ieșire după destinație și politică, nu după interfața pe care a folosit-o telefonul. Două asocieri simultane care dețin același IP virtual cu politici coincidente lasă decizia de rutare fără o modalitate de a spune cărei sesiuni îi aparține un răspuns. Unele răspunsuri iau tunelul greșit, iar telefonul arată o conexiune care funcționează într-un sens sau moare când apare Wi-Fi. Două ieșiri de comandă dovedesc starea: swanctl --list-sas arată același IP virtual pe ambele SA, iar ip xfrm policy arată doi selectori identici.

Exact acea pereche de ieșiri este cea pe care o lipiți în registrul de modificări. Niciuna singură nu este convingătoare, pentru că fiecare poate părea plauzibilă separat.

Aceasta este adresare și politică pe partea serverului, nu comportament greșit al telefonului, și nicio setare a clientului nu separă două adrese interne identice. Bazinul a emis aceeași valoare de două ori, iar instalatorul de politici a acceptat-o. Citiți rezultatul din partea serverului înainte de a da vina pe client.

Schimbați bazinul sau modelul de concurență, nu temporizatorul de rekey

În configurația swanctl, unicitatea este o politică explicită pe conexiune: unique = replace elimină o conexiune mai veche când se stabilește una nouă, iar unique = keep respinge noul venit. Ambele valori acționează când se configurează o conexiune, nu asupra SA-urilor copil din ea.

connections {
  ios-alwayson {
    unique = replace
  }
}

Nicio valoare nu este neutră pentru un client pe interfață. keep restaurează un ecran de stare curat refuzând al doilea tunel și rupe proiectarea administrată, în timp ce replace dărâmă tunelul mai vechi și este același compromis în direcția opusă. Dacă ambele tuneluri sunt cu adevărat necesare, backend-ul bazinului trebuie să emită lease-uri diferite pentru o identitate, iar cheia sa de lease trebuie să distingă cererile. Un tabel static identitate-la-adresă va returna bucuros aceeași adresă de două ori și va reproduce problema inițială cu mai multă configurație. Verificați cum backend-ul generează cheile de lease înainte de a adăuga o a doua mapare statică.

Testați tranzițiile pe care chiar le implementați

Ieșiți din raza Wi-Fi cu o sesiune activă, apoi reveniți, și verificați că răspunsurile sosesc în ambele sensuri. Faceți asta de două ori, pentru că a doua tranziție este locul unde apare de obicei o politică învechită. Testați cu un serviciu care răspunde pe conexiunea pe care ați deschis-o, și repetați ieșirea în timp ce tunelul transportă trafic în loc să stea inactiv. Un telefon care poate trimite dar nu poate primi pare sănătos într-un jurnal de handshake și stricat într-un browser.

Un ecran de stare redus la un singur rând nu este dovada unui proiect funcțional, doar dovada că un tunel a dispărut. Ambele sensuri trebuie să funcționeze înainte ca o tranziție să treacă. Notați ce ați observat, împreună cu cele două ieșiri ale verificării suprapunerii, ca următorul inginer să poată compara în loc să repete plimbarea.