Kaks iPhone'i VPN-i korraga: milline kannab sinu liiklust?

Kaks VPN-rakendust näitavad mõlemad Connected olekut ja eeldatakse, et liiklus käib nüüd läbi mõlema, üks teise sees. Tavaliselt see nii ei ole. iOS-il on kindel kooseksisteerimise mudel ja see ei ole ahel. Üks konfiguratsiooniklass on piiratud ühe lubatud eksemplariga, teine võib kõrvuti töötada, ja marsruudi prioriteet otsustab konfliktid. Kaks sisselülitatud lülitit ei ole kaks hüpet. Mudel on dokumenteeritud, mis tähendab, et teed saab ette ennustada, mitte ikoonide järgi oletada.

Müüt: kaks ühendatud VPN-i on ahel

Kahe hüppe ahel vajab määratletud välist transporti, määratletud sisemist tunnelit, ühilduvat otspunktide marsruutimist ja plaani, mis juhtub, kui kumbki neist ebaõnnestub. Kaks sõltumatut konfiguratsiooni ei loo seda lihtsalt samal ajal eksisteerides. Marsruudi prioriteet ei ole sama mis kapseldamine, ja see, et üks konfiguratsioon võidab marsruudiotsingu, ei ütle midagi selle kohta, kas teine kannab tekkivaid pakette.

Kui vajate pesastamist, projekteerige see pesastamisena. Ärge tuletage seda kahest ühenduse indikaatorist. See erinevus säästab palju silumist.

Selle müüdi taga olev dokumenteeritud mudel

Apple'i NETunnelProviderManager kirjeldab tavalisi ettevõtte VPN-konfiguratsioone ja märgib, et korraga saab lubada ainult ühe seda tüüpi. Sama viide lubab Personal VPN-il jääda selle kõrval lubatuks ja ühendatuks ning annab ettevõtte marsruutidele ülekaalu seal, kus need kattuvad.

Siin on Personal VPN API-termin sisseehitatud IPsec- või IKEv2-teostuse kohta, mida haldab NEVPNManager. NETunnelProviderManager on tunnelipakkuja mudel. Tarbijarakendus võib kasutada pakkuja mudelit, nii et personal sisaldav tootenimi ei liigita seda.

Apple dokumenteerib ühe lubatud kombinatsiooni, ja luba ei ütle teile, et kahe tarnija profiilid on ühilduvad, seega küsige igalt tarnijalt, milline paar on toetatud. Nende konfiguratsioonitüübid, marsruudid ja poliitikad otsustavad endiselt tulemuse.

Müüt: isiklik VPN saab sirvimisliikluse

Tööprofiil, mis nõuab kõiki sihtkohti, võidab marsruudiotsingu ka avaliku sirvimise jaoks, nii et isiklik väljund ei kanna sellest midagi. Dokumenteeritud prioriteedi kohaselt võidavad ettevõtte marsruudid seal, kus need põrkuvad, nii et avalik sirvimine ei võta automaatselt isiklikku väljundit ainult sellepärast, et see rakendus teatab samuti ühendusest. Kitsam töökonfiguratsioon võib marsruutimispilti muuta, kuid organisatsiooni klient võib siiski kehtestada DNS-i, blokeerimise või seadme nõudeid. Hankige toetatud korraldus selle omanikult, selle asemel et neid nõudeid kohapeal muuta.

Hallatavatel rakendusepõhistel konfiguratsioonidel on oma ulatus. Ärge laiendage seadmetasandi reeglit igale hallatavale juurutusele.

Kirjutage kaks voogu enne testimist üles: tööteenuse privaatne nimi ja vahemik ning värske avaliku sirvimise taotlus. Mõlemad on legitiimsed ja vajavad erinevaid kontrolle.

Marsruudi prioriteet jagatud tunneliga tööprofiili puhul

Jagatud tunneliga tööprofiil nõuab privaatseid prefikseid ja sisemist DNS-järelliidet, mille see loetleb, ja need marsruudid võidavad iga otsingu, mis nendega sobib. Avalikud sihtkohad, mis ei sobi ühegi ettevõtte marsruudiga, langevad füüsilisele lingile, kui isiklik VPN neid esimesena ei nõua. Prioriteedireegel otsustab ainult kattuvad vasted, seetõttu tuleb kahte profiili lugeda marsruuditabelitena, mitte ikoonidena.

Kirjutage paar kahe reana ja nimetage igaühe eeldatav võitja: tööhosti nimi, mis laheneb aadressile 10.x või 172.16.x, peaks väljuma ettevõtte tunnelist, ja avalik aadress, millel pole sobivat prefiksit, peaks võtma järelejäänud vaikimisi marsruudi. Kui mõlemad read nimetavad sama väljundi, ei tee jagamine seda, mida dokumentatsioon kirjeldab.

Kirjutage kaks voogu üles ja testige kumbagi

Iga voo puhul märkige, milline kinnitatud konfiguratsioon peaks seda kandma ja milline resolver peaks saama igat tüüpi nime. Seejärel kontrollige värskete taotlustega, mitte vahemällu salvestatud töölehe või vana IP-tulemusega.

Peatage üks konfiguratsioon ja korrake mõlemat voogu. Tõrkekäitumine on osa disainist ja see on osa, mida kasutajad märkavad. Kui kaks pakkujat ei suuda kombinatsiooni toetada, otsustage ühe kinnitatud konfiguratsiooni kasuks ja dokumenteerige, millist voogu see kannab, või liikuge hallatava ühe tunneliga lahenduse juurde. NETunnelProviderManageri dokumentatsioon on kooseksisteerimisreegli allikas.