Vai viens VPN pakalpojums var aptvert Windows, Mac un Linux darbvirsmas?

Trīs klēpjdatori vienā komandā, trīs dažādas VPN izvēlnes un pieteikums, kurā teikts, ka savienojums strādā visur, izņemot Mac. Plāns aiz šiem klientiem var būt identisks arī tad, ja izvēlnes nav. Saskanēt ir jāmazāk, nekā pieņem lielākā daļa ieviešanu: viena vārtejas identitāte, viens akreditācijas datu veids, viena maršrutu kopa un viena atrisinātāja politika. Pierakstiet šos četrus punktus, pirms kāds eksportē profilu, un platformu darbs pārvēršas kontrolsarakstā, nevis izmeklēšanā.

Sāciet ar piekļuves līgumu, nevis klienta failu

Piekļuves līgums ir piecas rindas, kuras pārskatītājs var pārbaudīt, neatverot piegādātāja konsoli. Tajā nosaukti privātie prefiksi, kuriem jābūt sasniedzamiem, iekšējie nosaukumi, kuri jāatrisina, atrisinātājs, kas uz tiem atbild, trafiks, kam atļauts palikt vietējā ceļā, un vārtejas sertifikāts, kuru klientam vajadzētu sagaidīt. Viss pārējais ieviešanā ir šo rindu tulkojums faila formātā.

Biroja piemērs padara formu konkrētu: lietojumprogrammu serveri 10.60.0.0/16, privātie nosaukumi zem corp.example, iekšējais atrisinātājs 10.61.0.53, bet parastā pārlūkošana paliek ceļā, kuru ierīce jau izmanto. Pēdējais punkts ir politikas lēmums, nevis klienta noklusējums, un vairāki klienti sūtīs visu pa tuneli, ja neviens nepasaka citādi. Fiksējiet līgumu ar datumu un atbildīgo, jo tieši šis ieraksts vēlāk pateiks, vai mainījās tunelis vai politika.

Izvēlieties vienu protokolu un vienu autentifikācijas pāri, ko spējat aizstāvēt

IKEv2 ar sertifikātos balstītu vārtejas autentifikāciju un EAP lietotājam ir ierastā izvēle, kad visām trim platformām jāstrādā bez papildu programmatūras, jo Windows, macOS un NetworkManager katra piegādā IKEv2 klientu. Nezināšana ir tajā, ka IKEv2 atbalsts apraksta etiķeti, nevis funkciju kopu. EAP metodes, aparatūras atbalstītas atslēgas, sertifikāta piesaiste kontam un automātiska atkārtota savienošana tiek ieviestas katrai platformai atsevišķi. Kombinācija, kas strādā divās no trim, ir pietiekami izplatīta, lai to uzskatītu par pašsaprotamu, līdz tā ir pārbaudīta.

Pārbaudiet pāri katrā mērķa platformā pirms ieviešanas rokasgrāmatas rakstīšanas, nevis pēc tam. Vārteja, kas piedāvā gan EAP-MSCHAPv2, gan EAP-TLS, dod vietu rezerves ceļam, ja vien šis rezerves ceļš ir dokumentēts kā atbalstīts, nevis atklāts incidenta laikā. Divi atbalstīti ceļi ir lēta apdrošināšana; nedokumentēts trešais ceļš ir nākotnes pieteikums.

Kad neviena pāri nesedz visus trīs klientus, godīgās iespējas ir pievienot klientu, pievienot profilu vārtejā vai sašaurināt atbalstīto platformu sarakstu. Sertifikātu validācijas izslēgšana platformā, kas sūdzas viskaļāk, nav viena no tām. Šīs izmaiņas pārvērš saderības robu pārtveršanas riskā, un neviens vēlāks ieviešanas solis to nelabo.

Izveidojiet vienu artefaktu katrai platformai no līguma

Windows izmanto VPNv2 profilu, kas piegādāts ar MDM vai izveidots lokāli ar Add-VpnConnection un tā XML kravu. Kodas divas lietas: apjoms un uzticēšanās. Ierīces apjoma profils un lietotāja apjoma profils tiek instalēti dažādās krātuvēs, tāpēc klientam nepieciešamajam sertifikātam jāatrodas krātuvē, kas atbilst izvēlētajam apjomam. Nepareiza savienošana pāros rada profilu, kas importējas tīri un pēc tam neizdodas pirmajā savienojumā.

macOS izmanto konfigurācijas profilu ar pārvaldītu VPN kravu, parakstītu un izplatītu ar MDM vai instalētu manuāli pilotam. Identitāte un CA ķēde ceļo kā atsevišķas kravas, tāpēc profils var instalēties bez iebildumiem un tomēr neizdoties savienošanas brīdī. Pārbaudiet kravu sarakstu, ne tikai instalācijas rezultātu.

Linux ir atkarīga no aizmugures aiz NetworkManager, un strongSwan kopā ar NetworkManager spraudni ir atsevišķas pakotnes. Savienojuma īpašības ir spraudnim raksturīgas, nevis vispārīgas VPN atslēgas, tāpēc atslēga, kas nokopēta no cita spraudņa, bieži saglabājas bez kļūdas un pēc tam neizdodas aktivizēšanā. Izveidojiet savienojumu tīrā attēlā, lai apstiprinātu, ka spraudnis ir tur, kur tas patiešām darbosies.

Trīs artefakti atšķiras pēc formāta, bet katrs kodē tās pašas piecas līguma rindas. Tas ir tests, vai artefakts ir pabeigts: katra rinda kaut kur ir attēlota, un pa ceļam nav izdomāts nekas lieks.

Pārbaudiet maršrutus, atrisinātāju un atkārtotu savienošanu tīrā kontā

Savienots nav pieņemšanas tests. Windows Get-VpnConnection rāda profilu, un route print rāda, vai privātais prefikss nonāca tuneļa saskarnē. macOS scutil --nc list apstiprina aktīvo pakalpojumu, kamēr scutil --dns rāda atrisinātāju secību, kuru sistēma patiešām izmantos.

Linux nmcli connection show --active pierāda, ka savienojums ir aktīvs, un resolvectl status rāda DNS pa saitēm. Atrisinātājs, kas ir savienojuma failā, bet nav izvadē pa saitēm, nozīmē, ka sadalītais DNS netiek piemērots. Tā ir atšķirība starp nosaukumiem, kas atrisinās, un nosaukumiem, kas atrisinās pa tuneli, un tā maina to, kura atbalsta komanda uzņemas nākamo soli. Salīdziniet izvadi pa saitēm pirms un pēc savienojuma pacelšanas, ne tikai pēc tam.

Veiciet visu pārbaudi jaunā kontā, bez kešotiem akreditācijas datiem un bez administratora instalēta sertifikāta. Pēc tam atkārtojiet to pēc apturēšanas un atsākšanas, un vēlreiz pēc akreditācijas datu atkārtotas ievades piespiešanas. Šīs divas pārejas atklāj lielāko daļu atkārtotas savienošanas kļūmu, ko pirmais savienojums nekad neparāda.

Versijojiet pakotni un saglabājiet atritināšanas ceļu

Atzīmējiet katru platformas pakotni ar līguma redakciju, ko tā īsteno, un pierakstiet klienta un vārtejas versijas, ar kurām to pieņēmāt. Kad uzvedība mainās pēc klienta atjauninājuma, atzīme norāda uz līgumu, kas jāpārbauda no jauna, nevis uz failu, kas jāmin.

Turiet iepriekšējo katras platformas pakotni pieejamu un blakus pierakstiet tās noņemšanas komandu. VPN profila atinstalēšana nav instalēšanas spoguļattēls ne Windows, ne macOS, ne Linux gadījumā, un atšķirības parādās vissliktākajā brīdī. Vienreiz izmēģiniet noņemšanu rezerves ierīcē, lai arhīvs kļūtu par plānu, nevis cerību.