iPhone Always On VPN: dalawang tunnel ay maaaring magbahagi ng isang virtual na IP

Sa isang pinangangasiwaang iPhone na may pinamamahalaang Always On profile, may tunnel ang telepono para sa bawat aktibong IP interface, kaya ang cellular at Wi-Fi ay may tig-isa. Pagkatapos ay naglilista ang server ng dalawang IKE security association para sa isang device, kadalasang nagbabahagi ng isang virtual na address, at ang unang instinct ay tawagin itong rekey loop at simulan ang pagbabago ng mga timer. Ang instinct na iyon ay karaniwang mali. Sundin ang mga hakbang sa ibaba sa pagkakasunod-sunod kung saan lumilitaw ang ebidensya sa server, at iwanan ang mga setting ng telepono hanggang sabihin ng server kung aling kaso ang mayroon ka.

Magsimula sa dalawang hilera na mayroon na ang server

Ilista ang mga association gamit ang swanctl --list-sas at basahin ang apat na field sa parehong entry: ang malayong address, ang na-authenticate na pagkakakilanlan, ang itinalagang virtual na IP, at ang oras ng paglikha. Dalawang magkaibang panlabas na address na may isang pagkakakilanlan at isang virtual na IP ang hugis na nagsimula ng tanong na ito, at sulit itong isulat bago ang anumang pagbabago. Pagkatapos ay suriin ang mga child association na nakakabit sa bawat isa, dahil ang mga traffic selector ang nagpapasya kung ang paghahanap ng destinasyon ay makakapaghiwalay kailanman sa dalawang tunnel. Ang pares na lumilitaw at nawawala sa loob ng ilang segundo ay ibang hayop kaysa sa pares na parehong nabubuhay nang maraming oras.

Bago magbigay ng konklusyon, ayusin ang listahan ayon sa oras ng paglikha. Walang ibig sabihin ang pagkakalapit sa output, at ang listahang hugis-talahanayan ay nag-aanyaya mismo sa pagkakamaling iyon.

Magpasya kung aling overlap ang tinitingnan mo

Ang IKEv2 rekey at make-before-break reauthentication ay sadyang gumagawa ng maikling overlap, na itinatag ang bagong association bago tanggalin ang luma. Ang mga timestamp ang magpapasya sa kaso, dahil ang lumang SA na nawawala isang segundo o dalawa pagkatapos lumitaw ang bago ay renewal na ginagawa ang trabaho nito. Ang mga independenteng interface tunnel ay hindi kailanman ganito ang hitsura, dahil bawat isa ay nananatili hangga't bukas ang interface nito, at ang pagtanggal ng isa ay hindi nagmumula sa paggawa ng isa pa.

Ang pinamamahalaang Always On na pag-uugali ng Apple ay kada interface, kaya ang isang pinangangasiwaang device ay maaaring lehitimong magmukhang mas abala kaysa sa profile na mano-manong na-configure. Ang auto-connect toggle ng app ng provider ay hindi nangangahulugan ng pareho, at ang ordinaryong on-demand na tuntunin ay gayundin. Ang pangkalahatang-tanaw ng deployment ng Apple ay naglalarawan ng modelong kada interface; ihambing ang iyong dalawang hilera dito bago magpalagay ng loop. Ang parehong hugis ay kumukuha rin mula sa parehong server pool, kaya ang overlap ang tanging maagang senyales mo.

Tingnan kung bakit ang isang virtual na address para sa dalawang tunnel ay sumisira sa mga sagot

Ang sagot sa telepono ay naka-address sa panloob na address, at ang kernel ay pumipili ng outbound tunnel ayon sa destinasyon at patakaran, hindi ayon sa interface na ginamit ng telepono. Dalawang sabay na association na may parehong virtual na IP at magkatugmang patakaran ay iniiwan ang routing decision na walang paraan upang sabihin kung aling session nabibilang ang isang sagot. Ang ilang sagot ay kumukuha ng maling tunnel, at ang telepono ay nagpapakita ng koneksyon na gumagana sa isang direksyon o namamatay kapag umangat ang Wi-Fi. Dalawang output ng command ang nagpapatunay ng estado: swanctl --list-sas ay nagpapakita ng parehong virtual na IP sa dalawang SA, at ip xfrm policy ay nagpapakita ng dalawang magkatulad na selector.

Ang pares ng output na iyon ang ipinapasa mo sa talaan ng pagbabago. Wala sa kanila ang nakakumbinsi nang mag-isa, dahil ang bawat isa ay maaaring magmukhang makatwiran nang mag-isa.

Ito ay addressing at patakaran sa panig ng server, hindi maling pag-uugali ng telepono, at walang setting ng client ang naghihiwalay sa dalawang magkatulad na panloob na address. Dalawang beses na ibinigay ng pool ang parehong halaga at tinanggap ito ng installer ng patakaran. Basahin ang resulta mula sa panig ng server bago sisihin ang client.

Palitan ang pool o ang modelo ng concurrency, hindi ang rekey timer

Sa swanctl configuration, ang uniqueness ay isang tahasang patakaran sa koneksyon: tinatanggal ng unique = replace ang mas lumang koneksyon kapag may naitatag na bago, at tinatanggihan ng unique = keep ang bagong dating. Ang parehong halaga ay kumikilos kapag inaayos ang isang koneksyon, hindi sa mga child SA sa loob nito.

connections {
  ios-alwayson {
    unique = replace
  }
}

Wala sa mga halaga ang neutral para sa client kada interface. Ibinalik ng keep ang maayos na status screen sa pamamagitan ng pagtanggi sa ikalawang tunnel at sinisira ang pinamamahalaang disenyo, habang binabagsak ng replace ang mas lumang tunnel at ito rin ang parehong kompromiso sa kabilang direksyon. Kung talagang kailangan ang dalawang tunnel, kailangang maglabas ang backend ng pool ng magkaibang lease para sa isang pagkakakilanlan, at ang key ng lease nito ay kailangang maghiwalay ng mga kahilingan. Ang static na talahanayang pagkakakilanlan-sa-address ay malugod na ibabalik ang parehong address nang dalawang beses at muling gagawin ang orihinal na problema nang may mas maraming configuration. Suriin kung paano ginagawa ng backend ang mga key ng lease bago magdagdag ng ikalawang static na mapping.

Subukan ang mga transition na talagang ine-deploy mo

Lumabas sa saklaw ng Wi-Fi habang may aktibong session, pagkatapos ay bumalik, at suriin na dumarating ang mga sagot sa dalawang direksyon. Gawin ito nang dalawang beses, dahil sa ikalawang transition madalas lumitaw ang lipas na patakaran. Subukan gamit ang serbisyo na tumutugon sa koneksyong binuksan mo, at ulitin ang paglabas habang may dalang trapiko ang tunnel sa halip na nakatigil. Ang teleponong nakakapagpadala ngunit hindi nakakatanggap ay mukhang malusog sa handshake log at sira sa browser.

Ang status screen na binawasan sa isang hilera ay hindi patunay ng gumaganang disenyo, patunay lamang na may isang tunnel na nawala. Kailangang gumana ang dalawang direksyon bago pumasa ang isang transition. Isulat ang naobserbahan mo, kasama ang dalawang output ng overlap check, upang ang susunod na inhinyero ay makapaghambing sa halip na ulitin ang lakad.