iPhone Always On VPN: divi tuneļi var dalīt vienu virtuālo IP

Uzraudzītā iPhone ar pārvaldītu Always On profilu tālrunis tur tuneli katrai aktīvai IP saskarnei, tāpēc mobilais tīkls un Wi-Fi katrs iegūst savējo. Pēc tam serveris vienai ierīcei uzskaita divas IKE drošības asociācijas, bieži kopīgojot vienu virtuālo adresi, un pirmā vēlme ir nosaukt to par rekey cilpu un sākt mainīt taimerus. Šī vēlme parasti ir nepareiza. Izejiet tālāk minētos soļus tādā secībā, kādā pierādījumi parādās serverī, un atstājiet tālruņa iestatījumus mierā, līdz serveris pasaka, kurš gadījums jums ir.

Sāciet ar tām divām rindām, kas serverim jau ir

Uzskaitiet asociācijas ar swanctl --list-sas un izlasiet četrus laukus abos ierakstos: attālo adresi, autentificēto identitāti, piešķirto virtuālo IP un izveides laiku. Divas atšķirīgas ārējās adreses ar vienu identitāti un vienu virtuālo IP ir forma, kas sāka šo jautājumu, un to ir vērts pierakstīt pirms jebkādām izmaiņām. Pēc tam pārbaudiet katrai piesaistītās pakārtotās asociācijas, jo trafika selektori izlemj, vai galamērķa meklēšana kādreiz varētu atšķirt abus tuneļus. Pāris, kas parādās un pazūd sekundēs, ir cits dzīvnieks nekā pāris, kas abi dzīvo stundām.

Pirms secinājuma izdarīšanas sakārtojiet sarakstu pēc izveides laika. Blakusatrasšanās izvadē neko nenozīmē, un tabulas formāta saraksts tieši aicina uz šo kļūdu.

Izlemiet, kuru pārklāšanos jūs skatāties

IKEv2 rekey un make-before-break atkārtota autentifikācija apzināti rada īsu pārklāšanos, izveidojot jauno asociāciju pirms vecās dzēšanas. Laika zīmogi izšķir gadījumu, jo vecs SA, kas pazūd sekundi vai divas pēc jaunā parādīšanās, ir atjaunošana, kas dara savu darbu. Neatkarīgi saskarnes tuneļi nekad neizskatās tā, jo katrs pastāv, kamēr tā saskarne ir augšā, un viena dzēšana neizriet no otra izveides.

Apple pārvaldītā Always On uzvedība ir pa saskarnēm, tāpēc uzraudzīta ierīce var likumīgi izskatīties aizņemtāka nekā ar roku iestatīts profils. Pakalpojumu sniedzēja lietotnes automātiskās savienošanas slēdzis nenozīmē to pašu, un parasta on-demand kārtula arī ne. Apple izvietošanas pārskats apraksta modeli pa saskarnēm; salīdziniet savas divas rindas ar to, pirms pieņemat cilpu. Abas formas arī smeļas no viena servera baseina, tāpēc pārklāšanās ir vienīgais agrīnais signāls.

Skatiet, kāpēc viena virtuālā adrese diviem tuneļiem salauž atbildes

Atbilde tālrunim tiek adresēta iekšējai adresei, un kodols izejošo tuneli izvēlas pēc galamērķa un politikas, nevis pēc saskarnes, ko izmantoja tālrunis. Divas vienlaicīgas asociācijas, kurām ir viens un tas pats virtuālais IP un sakrītošas politikas, atstāj maršrutēšanas lēmumu bez veida pateikt, kurai sesijai atbilde pieder. Dažas atbildes nonāk nepareizajā tunelī, un tālrunis rāda savienojumu, kas darbojas vienā virzienā vai mirst, kad paceļas Wi-Fi. Divi komandu izvadi pierāda stāvokli: swanctl --list-sas rāda to pašu virtuālo IP abos SA, un ip xfrm policy rāda divus identiskus selektorus.

Tieši šo izvadu pāri jūs ielīmējat izmaiņu žurnālā. Neviens viens pats nav pārliecinošs, jo katrs atsevišķi var izskatīties ticams.

Tā ir servera puses adresācija un politika, nevis nepareiza tālruņa uzvedība, un neviens klienta iestatījums neatdala divas identiskas iekšējās adreses. Baseins divreiz izdeva to pašu vērtību, un politikas instalētājs to pieņēma. Izlasiet rezultātu no servera puses, pirms vainojat klientu.

Mainiet baseinu vai paralēlisma modeli, nevis rekey taimeri

swanctl konfigurācijā unikalitāte ir skaidra politika savienojumam: unique = replace noņem vecāku savienojumu, kad tiek izveidots jauns, un unique = keep noraida jaunpienācēju. Abas vērtības iedarbojas, kad savienojums tiek iestatīts, nevis uz tā iekšējiem pakārtotajiem SA.

connections {
  ios-alwayson {
    unique = replace
  }
}

Neviena vērtība nav neitrāla klientam pa saskarnēm. keep atjauno kārtīgu statusa ekrānu, atsakot otro tuneli, un salauž pārvaldīto dizainu, bet replace nogāž vecāko tuneli un ir tāds pats kompromiss pretējā virzienā. Ja abi tuneļi tiešām ir vajadzīgi, baseina aizmugurei ir jāizdod atšķirīgas nomes vienai identitātei, un tās nomes atslēgai ir jāatšķir pieprasījumi. Statiska identitātes-uz-adresi tabula labprāt atgriezīs to pašu adresi divreiz un atkārtos sākotnējo problēmu ar vairāk konfigurācijas. Pārbaudiet, kā aizmugure veido nomes atslēgas, pirms pievienojat otru statisko kartējumu.

Pārbaudiet pārejas, ko patiešām ieviešat

Izejiet no Wi-Fi diapazona ar aktīvu sesiju, pēc tam atgriezieties, un pārbaudiet, ka atbildes pienāk abos virzienos. Dariet to divreiz, jo otrais pārejas brīdis ir vieta, kur parasti parādās novecojusi politika. Pārbaudiet ar pakalpojumu, kas atbild jūsu atvērtajā savienojumā, un atkārtojiet izeju, kamēr tunelis nes trafiku, nevis stāv dīkā. Tālrunis, kas var sūtīt, bet nevar saņemt, izskatās vesels rokasspiediena žurnālā un salūzis pārlūkā.

Statusa ekrāns, kas sašaurināts līdz vienai rindai, nav strādājoša dizaina pierādījums, tikai pierādījums, ka viens tunelis ir pazudis. Abiem virzieniem jādarbojas, pirms pāreja iztur. Pierakstiet, ko novērojāt, kopā ar diviem pārklāšanās pārbaudes izvadiem, lai nākamais inženieris varētu salīdzināt, nevis atkārtot pastaigu.