Může jedna VPN služba pokrýt desktopy Windows, Mac a Linux?

Tři notebooky v jednom týmu, tři různá menu VPN a tiket, který tvrdí, že připojení funguje všude kromě Macu. Plán za těmito klienty může být stejný, i když menu stejná nejsou. To, co musí sedět, je užší, než většina zavádění předpokládá: jedna identita brány, jeden typ přihlašovacího údaje, jedna sada tras a jedna politika resolveru. Zapište ty čtyři věci dřív, než někdo exportuje profil, a práce s platformami se změní v kontrolní seznam místo vyšetřování.

Začněte přístupovou smlouvou, ne klientským souborem

Přístupová smlouva je pět řádků, které recenzent ověří, aniž by otevřel konzoli dodavatele. Pojmenovává privátní prefixy, které musí být dostupné, interní názvy, které se musí přeložit, resolver, který na ně odpovídá, provoz, kterému je dovoleno zůstat na lokální cestě, a certifikát brány, který má klient očekávat. Všechno ostatní v zavádění je překlad těchto řádků do formátu souboru.

Příklad z kanceláře dává podobě konkrétní tvar: aplikační servery v 10.60.0.0/16, privátní názvy pod corp.example, interní resolver na 10.61.0.53 a běžné prohlížení ponechané na cestě, kterou zařízení už používá. Poslední bod je rozhodnutí o politice, ne výchozí hodnota klienta, a několik klientů pošle všechno tunelem, pokud nikdo neřekne jinak. Zaznamenejte smlouvu s datem a vlastníkem, protože právě tento záznam vám později řekne, zda se změnil tunel, nebo politika.

Vyberte jeden protokol a jeden pár autentizace, který dokážete obhájit

IKEv2 s autentizací brány založenou na certifikátu a EAP pro uživatele je obvyklá volba, když všechny tři platformy musí fungovat bez dalšího softwaru, protože Windows, macOS i NetworkManager každý dodávají klienta IKEv2. Problém je, že podpora IKEv2 popisuje štítek, ne sadu funkcí. Metody EAP, klíče s hardwarovou podporou, mapování certifikátu na účet a automatické opětovné připojení se implementují zvlášť pro každou platformu. Kombinace, která funguje na dvou ze tří, je dost běžná na to, abyste ji předpokládali, dokud ji neotestujete.

Otestujte pár na každé cílové platformě před napsáním průvodce zaváděním, ne po něm. Brána nabízející EAP-MSCHAPv2 i EAP-TLS vám dává prostor pro návrat, za předpokladu, že návrat je zdokumentovaný jako podporovaný, a ne objevený během incidentu. Dvě podporované cesty jsou levná pojistka; nezdokumentovaná třetí cesta je budoucí tiket.

Když žádný pár nepokrývá všechny tři klienty, poctivé možnosti jsou přidat klienta, přidat profil brány nebo zúžit seznam podporovaných platforem. Vypnout ověřování certifikátů na platformě, která si stěžuje nejhlasitěji, mezi ně nepatří. Tato změna mění mezeru v kompatibilitě v riziko odposlechu a žádný pozdější krok zavádění ji nenapraví.

Sestavte jeden artefakt pro každou platformu ze smlouvy

Windows přebírá profil VPNv2, dodaný přes MDM nebo vytvořený lokálně pomocí Add-VpnConnection a jeho XML nákladu. Bolí rozsah a důvěra. Profil s rozsahem zařízení a profil s rozsahem uživatele se instalují do různých úložišť, takže certifikát, který klient potřebuje, musí být v úložišti odpovídajícím zvolenému rozsahu. Špatné spárování dá profil, který se čistě naimportuje a pak selže při prvním připojení.

macOS přebírá konfigurační profil se spravovaným nákladem VPN, podepsaný a odeslaný přes MDM nebo ručně nainstalovaný pro pilot. Identita a řetězec CA cestují jako samostatné náklady, a proto se profil může nainstalovat bez stížnosti a přesto selhat v okamžiku připojení. Zkontrolujte seznam nákladů, ne jen výsledek instalace.

Linux závisí na backendu za NetworkManagerem a strongSwan a plugin NetworkManageru jsou samostatné balíčky. Vlastnosti připojení jsou specifické pro plugin, ne obecné klíče VPN, takže klíč zkopírovaný z jiného pluginu se často uloží bez chyby a pak selže při aktivaci. Sestavte připojení na čistém obrazu, abyste potvrdili, že plugin je tam, kde skutečně poběží.

Tři artefakty se liší formátem, ale každý kóduje stejných pět řádků smlouvy. To je test, zda je artefakt hotový: každý řádek je někde zastoupen a nic navíc nebylo vymyšleno.

Ověřte trasy, resolver a opětovné připojení na čistém účtu

Připojeno není akceptační test. Ve Windows Get-VpnConnection ukazuje profil a route print ukazuje, zda privátní prefix dosedl na rozhraní tunelu. Na macOS scutil --nc list potvrzuje aktivní službu, zatímco scutil --dns ukazuje pořadí resolverů, které systém skutečně použije.

V Linuxu nmcli connection show --active dokazuje, že připojení je nahoře, a resolvectl status ukazuje DNS pro každé rozhraní. Resolver přítomný v souboru připojení, ale chybějící ve výstupu pro rozhraní, znamená, že se rozdělený DNS neuplatňuje. To je rozdíl mezi názvy, které se překládají, a názvy, které se překládají tunelem, a mění, který tým podpory vlastní další krok. Porovnejte výstup pro rozhraní před a po nahození připojení, ne jen po něm.

Proveďte celou kontrolu na čerstvém účtu bez uložených přihlašovacích údajů a bez certifikátu nainstalovaného správcem. Poté ji zopakujte po uspání a probuzení a ještě jednou po vynuceném znovuzadání přihlašovacích údajů. Tyto dva přechody odhalí většinu selhání opětovného připojení, která první připojení nikdy neukáže.

Verzujte balíček a udržujte cestu zpět

Označte každý balíček platformy revizí smlouvy, kterou implementuje, a poznamenejte verze klienta a brány, proti nimž jste jej přijali. Když se chování po aktualizaci klienta změní, značka ukáže na smlouvu k opětovnému testu, ne na soubor k hádání.

Udržujte předchozí balíček pro každou platformu dostupný a napište vedle něj příkaz k odstranění. Odinstalace profilu VPN není zrcadlovým obrazem jeho instalace ve Windows, macOS nebo Linuxu a rozdíly se projeví v nejhorší možný okamžik. Jednou si odstranění vyzkoušejte na náhradním zařízení, aby se archiv stal plánem, ne nadějí.