Divi iPhone VPN vienlaikus: kurš pārvadā jūsu trafiku?

Divas VPN lietotnes abas rāda Connected, un tiek pieņemts, ka trafiks tagad iet caur abām, viena otras iekšienē. Parasti tas tā nenotiek. iOS ir noteikts līdzāspastāvēšanas modelis, un tā nav ķēde. Viena konfigurācijas klase ir ierobežota ar vienu iespējotu instanci, otra var darboties tam blakus, un maršrutu prioritāte izšķir konfliktus. Divi ieslēgti slēdži nav divi lēcieni. Modelis ir dokumentēts, kas nozīmē, ka ceļu var paredzēt, nevis minēt pēc ikonām.

Mīts: divi savienoti VPN ir ķēde

Divu lēcienu ķēdei vajadzīgs noteikts ārējais transports, noteikts iekšējais tunelis, saderīga galapunktu maršrutēšana un plāns, kas notiks, ja kāds no tiem neizdosies. Divas neatkarīgas konfigurācijas to nerada tikai ar to, ka pastāv vienlaikus. Maršruta prioritāte nav tas pats, kas iekapsulēšana, un tas, ka viena konfigurācija uzvar maršruta meklēšanā, neko neizsaka par to, vai otra pārvadā iegūtos paketes.

Ja jums vajag ligzdošanu, projektējiet to kā ligzdošanu. Neizdariet to no diviem savienojuma indikatoriem. Šī atšķirība ietaupa daudz atkļūdošanas.

Dokumentētais modelis aiz šī mīta

Apple NETunnelProviderManager apraksta parastas uzņēmuma VPN konfigurācijas un norāda, ka vienlaikus var iespējot tikai vienu no šāda veida. Tā pati atsauce ļauj Personal VPN palikt iespējotam un savienotam tam blakus, un piešķir uzņēmuma maršrutiem priekšroku vietās, kur abi pārklājas.

Šeit Personal VPN ir API termins iebūvētajai IPsec vai IKEv2 implementācijai, ko pārvalda NEVPNManager. NETunnelProviderManager ir tuneļa nodrošinātāja modelis. Patērētāja lietotne var izmantot nodrošinātāja modeli, tāpēc produkta nosaukums ar personal to neklasificē.

Apple dokumentē vienu atļautu kombināciju, un atļauja nepauž, ka divu piegādātāju profili ir saderīgi, tāpēc jautājiet katram piegādātājam, kurš pāris tiek atbalstīts. Viņu konfigurāciju veidi, maršruti un politikas joprojām izšķir rezultātu.

Mīts: personīgais VPN iegūst pārlūkošanas trafiku

Darba profils, kas pretendē uz visiem galamērķiem, uzvarēs arī maršruta meklēšanā publiskai pārlūkošanai, tāpēc personīgā izeja no tā neko nepārvadā. Saskaņā ar dokumentēto prioritāti uzņēmuma maršruti uzvar tur, kur tie saduras, tāpēc publiskā pārlūkošana automātiski neizmanto personīgo izeju tikai tāpēc, ka šī lietotne arī ziņo par savienojumu. Šaurāka darba konfigurācija var mainīt maršrutēšanas ainu, bet organizācijas klients joprojām var noteikt DNS, bloķēšanas vai ierīces prasības. Iegūstiet atbalstīto kārtību no tās īpašnieka, nevis rediģējiet šīs prasības lokāli.

Pārvaldītajām lietotnes konfigurācijām ir savs tvērums. Neattieciniet ierīces līmeņa noteikumu uz katru pārvaldīto izvietojumu.

Pirms testa pierakstiet divas plūsmas: darba pakalpojuma privāto nosaukumu un diapazonu, un jaunu publiskās pārlūkošanas pieprasījumu. Abas ir likumīgas, un tām vajadzīgas dažādas pārbaudes.

Maršrutu prioritāte ar sadalīta tuneļa darba profilu

Sadalīta tuneļa darba profils pretendē uz uzskaitītajiem privātajiem prefiksiem un iekšējo DNS sufiksu, un šie maršruti uzvar jebkuru meklēšanu, kas tiem atbilst. Publiskie galamērķi, kas neatbilst nevienam uzņēmuma maršrutam, nokļūst uz fiziskā savienojuma, ja vien personīgais VPN tiem nepretendē pirmais. Prioritātes noteikums izšķir tikai pārklājošās atbilstības, tāpēc abi profili jālasa kā maršrutu tabulas, nevis kā ikonas.

Pierakstiet pāri divās rindās un nosauciet katras paredzēto uzvarētāju: darba resursdatora nosaukumam, kas atrisinās uz 10.x vai 172.16.x, vajadzētu iziet caur uzņēmuma tuneli, un publiskai adresei bez atbilstoša prefiksa vajadzētu izmantot atlikušo noklusējuma maršrutu. Ja abas rindas nosauc vienu un to pašu izeju, sadalījums nedara to, ko apraksta dokumentācija.

Pierakstiet divas plūsmas un pārbaudiet katru

Katrai plūsmai pierakstiet, kurai apstiprinātajai konfigurācijai tā jāpārvadā un kuram atrisinātājam jāsaņem katrs nosaukuma veids. Pēc tam pārbaudiet ar jauniem pieprasījumiem, nevis ar kešatmiņā saglabātu darba lapu vai vecu IP rezultātu.

Apturiet vienu konfigurāciju un atkārtojiet abas plūsmas. Kļūmes uzvedība ir daļa no dizaina, un tā ir daļa, ko lietotāji ievēro. Kad divi nodrošinātāji nevar atbalstīt kombināciju, izlemiet par vienu apstiprinātu konfigurāciju un dokumentējiet, kuru plūsmu tā pārvadā, vai pārejiet uz pārvaldītu viena tuneļa dizainu. NETunnelProviderManager dokumentācija ir līdzāspastāvēšanas noteikuma avots.