iPhone Always On VPN: dva tunely môžu zdieľať jednu virtuálnu IP

Na dohliadanom iPhone so spravovaným profilom Always On drží telefón tunel pre každé aktívne IP rozhranie, takže mobilná sieť aj Wi-Fi majú každé svoj. Server potom vypíše dve IKE bezpečnostné asociácie pre jedno zariadenie, často zdieľajúc jednu virtuálnu adresu, a prvý impulz je nazvať to slučkou rekey a začať meniť časovače. Ten impulz je zvyčajne nesprávny. Prejdite kroky nižšie v poradí, v akom sa dôkazy objavujú na serveri, a nechajte nastavenia telefónu na pokoji, kým vám server nepovie, o ktorý prípad ide.

Začnite dvoma riadkami, ktoré server už má

Vypíšte asociácie pomocou swanctl --list-sas a prečítajte štyri polia v oboch záznamoch: vzdialenú adresu, overenú identitu, pridelenú virtuálnu IP a čas vytvorenia. Dve rôzne vonkajšie adresy s jednou identitou a jednou virtuálnou IP sú tvarom, ktorý túto otázku spustil, a stojí za to si ho zapísať pred akoukoľvek zmenou. Potom skontrolujte podriadené asociácie pripojené ku každej z nich, pretože selektory prevádzky rozhodujú, či by vyhľadanie cieľa mohlo niekedy rozlíšiť dva tunely. Pár, ktorý sa objaví a zmizne v priebehu sekúnd, je iné zviera než pár, ktorý oba žije hodiny.

Pred vyvodením záveru zoraďte zoznam podľa času vytvorenia. Susedstvo vo výstupe nič neznamená a tabuľkový výpis k tejto chybe priamo vyzýva.

Určte, na ktoré prekrytie sa pozeráte

Obnova kľúča IKEv2 a reautentizácia make-before-break zámerne vytvárajú krátke prekrytie: nová asociácia sa nadviaže skôr, než sa stará zmaže. Časové pečiatky prípad rozhodnú, pretože stará SA, ktorá zmizne sekundu alebo dve po objavení novej, je obnova, ktorá robí svoju prácu. Nezávislé tunely na rozhraniach tak nikdy nevyzerajú, pretože každý pretrváva, kým je jeho rozhranie aktívne, a zmazanie jedného nevyplýva z vytvorenia druhého.

Spravované správanie Always On od Apple je na rozhraní, preto môže dohliadané zariadenie legitímne vyzerať vyťaženejšie než ručne nastavený profil. Prepínač automatického pripojenia v aplikácii poskytovateľa neznamená to isté a obyčajné pravidlo on-demand tiež nie. Prehľad nasadenia Apple opisuje model na rozhraní; porovnajte svoje dva riadky s ním, kým budete predpokladať slučku. Oba tvary tiež čerpajú z toho istého fondu na serveri, takže prekrytie je váš jediný skorý signál.

Pozrite sa, prečo jedna virtuálna adresa pre dva tunely láme odpovede

Odpoveď telefónu je adresovaná na vnútornú adresu a jadro vyberá odchádzajúci tunel podľa cieľa a politiky, nie podľa rozhrania, ktoré telefón použil. Dve súbežné asociácie držiace rovnakú virtuálnu IP so zhodnými politikami nechávajú rozhodnutie o smerovaní bez spôsobu, ako povedať, ku ktorej relácii odpoveď patrí. Niektoré odpovede idú nesprávnym tunelom a telefón ukazuje spojenie, ktoré funguje jedným smerom alebo umrie, keď sa objaví Wi-Fi. Dva výstupy príkazov stav dokazujú: swanctl --list-sas ukazuje rovnakú virtuálnu IP na oboch SA a ip xfrm policy ukazuje dva totožné selektory.

Práve tento pár výstupov vložíte do záznamu o zmene. Ani jeden sám o sebe nie je presvedčivý, pretože každý môže vyzerať vierohodne samostatne.

Toto je adresovanie a politika na strane servera, nie nesprávne správanie telefónu, a žiadne nastavenie klienta neoddeľuje dve totožné vnútorné adresy. Fond vydal rovnakú hodnotu dvakrát a inštalátor politík ju prijal. Prečítajte výsledok zo strany servera, kým obviníte klienta.

Zmeňte fond alebo model súbežnosti, nie časovač rekey

V konfigurácii swanctl je jedinečnosť výslovnou politikou na spojení: unique = replace odstráni staršie spojenie, keď sa nové nadviaže, a unique = keep nováčika odmietne. Obe hodnoty pôsobia pri nastavovaní spojenia, nie na podriadené SA v ňom.

connections {
  ios-alwayson {
    unique = replace
  }
}

Ani jedna hodnota nie je pre klienta na rozhraní neutrálna. keep obnoví upratanú stavovú obrazovku tým, že druhý tunel odmietne, a rozbije spravovaný návrh, zatiaľ čo replace zrúti starší tunel a je tým istým kompromisom opačným smerom. Ak sú oba tunely skutočne potrebné, backend fondu musí pre jednu identitu vydávať odlišné leases a jeho kľúč lease musí požiadavky rozlíšiť. Statická tabuľka identita-na-adresu rada vráti rovnakú adresu dvakrát a pôvodný problém reprodukuje s viac konfigurácie. Pred pridaním druhého statického mapovania skontrolujte, ako backend kľúčuje leases.

Testujte prechody, ktoré skutočne nasadzujete

Odkráčajte z dosahu Wi-Fi s aktívnou reláciou, potom sa vráťte a skontrolujte, že odpovede dorazia v oboch smeroch. Urobte to dvakrát, pretože pri druhom prechode sa zvyčajne objaví zastaraná politika. Testujte službou, ktorá odpovedá na spojení, ktoré ste otvorili, a odchod zopakujte, keď tunel nesie prevádzku, namiesto toho, aby stál nečinne. Telefón, ktorý dokáže odosielať, ale nie prijímať, vyzerá zdravo v protokole handshake a rozbite v prehliadači.

Stavová obrazovka zúžená na jeden riadok nie je dôkazom funkčného návrhu, len dôkazom, že jeden tunel je preč. Oba smery musia fungovať, kým prechod prejde. Zapíšte, čo ste pozorovali, spolu s dvoma výstupmi kontroly prekrytia, aby ďalší inžinier mohol porovnávať namiesto opakovania prechádzky.