Du iPhone VPN vienu metu: kuris neša jūsų srautą?
Du prisijungę VPN iPhone įrenginyje nėra grandinė. Perskaitykite dokumentuotą sugyvenimo modelį ir patikrinkite, kuri konfigūracija neša kiekvieną srautą.
Dvi VPN programėlės abi rodo Connected, ir daroma prielaida, kad srautas dabar eina per abi, viena kitos viduje. Paprastai taip nebūna. iOS turi konkretų sugyvenimo modelį, ir tai nėra grandinė. Viena konfigūracijos klasė apribota vienu įjungtu egzemplioriumi, kita gali veikti šalia, o maršrutų prioritetas nusprendžia konfliktus. Du įjungti jungikliai nėra du šuoliai. Modelis dokumentuotas, todėl kelią galima numatyti, o ne spėti iš piktogramų.
Mitas: du prisijungę VPN yra grandinė
Dviejų šuolių grandinei reikia apibrėžto išorinio transporto, apibrėžto vidinio tunelio, suderinamo galinių taškų maršrutizavimo ir plano, kas nutiks, jei kuris nors iš jų suges. Dvi nepriklausomos konfigūracijos to nesukuria vien tuo, kad egzistuoja tuo pačiu metu. Maršruto prioritetas nėra tas pats kaip inkapsuliavimas, o tai, kad viena konfigūracija laimi maršruto paiešką, nieko nesako apie tai, ar kita neša gautus paketus.
Jei jums reikia įdėjimo, projektuokite jį kaip įdėjimą. Nedarykite išvados iš dviejų ryšio indikatorių. Šis skirtumas sutaupo daug derinimo.
Dokumentuotas modelis už šio mito
Apple NETunnelProviderManager aprašo įprastas įmonių VPN konfigūracijas ir nurodo, kad vienu metu galima įjungti tik vieną tokio tipo. Ta pati nuoroda leidžia Personal VPN likti įjungtai ir prijungtai šalia, o įmonės maršrutams suteikia pirmenybę ten, kur abu persidengia.
Čia Personal VPN yra API terminas, reiškiantis integruotą IPsec arba IKEv2 įgyvendinimą, valdomą per NEVPNManager. NETunnelProviderManager yra tunelio teikėjo modelis. Vartotojo programėlė gali naudoti teikėjo modelį, todėl produkto pavadinimas su personal jo neklasifikuoja.
Apple dokumentuoja vieną leidžiamą derinį, o leidimas nepasako, kad dviejų tiekėjų profiliai yra suderinami, todėl klauskite kiekvieno tiekėjo, kuri pora palaikoma. Jų konfigūracijų tipai, maršrutai ir politikos vis tiek lemia rezultatą.
Mitas: asmeninis VPN gauna naršymo srautą
Darbo profilis, kuris reikalauja visų paskirčių, laimės maršruto paiešką ir viešajam naršymui, todėl asmeninis išėjimas jo neneša. Pagal dokumentuotą pirmenybę įmonės maršrutai laimi ten, kur jie susikerta, todėl viešas naršymas automatiškai nepereina prie asmeninio išėjimo vien todėl, kad ta programėlė taip pat praneša apie ryšį. Siauresnė darbo konfigūracija gali pakeisti maršrutizavimo vaizdą, bet organizacijos klientas vis tiek gali nustatyti DNS, blokavimo ar įrenginio reikalavimus. Gaukite palaikomą tvarką iš jos savininko, o ne redaguokite tuos reikalavimus vietoje.
Tvarkomos programėlės konfigūracijos turi savo apimtį. Neperkelkite įrenginio lygio taisyklės į kiekvieną tvarkomą diegimą.
Prieš testą užrašykite du srautus: darbo paslaugos privatų pavadinimą ir diapazoną, ir naują viešo naršymo užklausą. Abu yra teisėti, ir jiems reikia skirtingų patikrų.
Maršrutų prioritetas su padalinto tunelio darbo profilu
Padalinto tunelio darbo profilis reikalauja išvardytų privačių prefiksų ir vidinės DNS priesagos, ir tie maršrutai laimi kiekvieną su jais sutampančią paiešką. Viešos paskirties vietos, kurios nesutampa su jokiu įmonės maršrutu, patenka į fizinę jungtį, nebent asmeninis VPN jų pareikalautų pirmas. Pirmenybės taisyklė nusprendžia tik persidengiančius atitikimus, todėl du profiliai turi būti skaitomi kaip maršrutų lentelės, o ne kaip piktogramos.
Užrašykite porą dviem eilutėmis ir nurodykite numatomą nugalėtoją kiekvienai: darbo hosto vardas, kuris sprendžiamas į 10.x arba 172.16.x, turėtų išeiti per įmonės tunelį, o viešas adresas be atitinkančio prefikso turėtų pasiimti likusį numatytąjį maršrutą. Jei abi eilutės nurodo tą patį išėjimą, skaidymas nedaro to, ką aprašo dokumentacija.
Užrašykite du srautus ir patikrinkite kiekvieną
Kiekvienam srautui užrašykite, kuri patvirtinta konfigūracija turėtų jį nešti ir kuris sprendėjas turėtų gauti kiekvieno tipo vardą. Tada patikrinkite naujomis užklausomis, o ne podėlyje esančiu darbo puslapiu ar senu IP rezultatu.
Sustabdykite vieną konfigūraciją ir pakartokite abu srautus. Gedimo elgsena yra dizaino dalis, ir tai yra dalis, kurią pastebi naudotojai. Kai du teikėjai negali palaikyti derinio, apsispręskite dėl vienos patvirtintos konfigūracijos ir dokumentuokite, kurį srautą ji neša, arba pereikite prie tvarkomo vieno tunelio dizaino. NETunnelProviderManager dokumentacija yra sugyvenimo taisyklės šaltinis.