Kāpēc SSL VPN un VPN starp vietnēm nav pretstati
SSL VPN un VPN starp vietnēm apraksta dažādas asis: kas pievienojas tīklam un kā tiek būvēts tunelis. Abus nosaukt kopā ir kategoriju kļūda.
Palūdziet diviem administratoriem aprakstīt vienu un to pašu VPN, un viens var atbildēt „SSL VPN“, bet otrs teikt „starp vietnēm“, it kā abi būtu konkurējošas izvēlnes iespējas. Tie ir atbildes uz dažādiem jautājumiem, un izturēšanās pret tiem kā pret alternatīvām rada salīdzinājumus, kurus nevar atrisināt. Viena etiķete norāda, kuri galapunkti tiek savienoti; otra – kas pārvadā satiksmi starp tiem. Turiet asis atsevišķi, un lielākā daļa strīda pazudīs.
Divas etiķetes, divi atsevišķi jautājumi
Topoloģija atbild, kas ar ko savienojas. Attālinātās piekļuves risinājums pievieno atsevišķus lietotājus vai ierīces pie vārtejas, parasti ar identitāti katram lietotājam un adrešu kopumu. Risinājums starp vietnēm savieno divus tīklus caur vārtejām, tāpēc interesantā identitāte ir partnera vārteja, nevis cilvēks pie tastatūras. Tie ir dažādi ekspluatācijas jautājumi, sākot no adrešu plānošanas līdz tam, kurš var atsaukt piekļuvi pulksten 2 naktī.
Mehānisms atbild, kā tunelis tiek būvēts un autentificēts. IPsec ar IKEv2, uz TLS balstīts produkts, kas pārvadā IP sevī, un pārlūkam vērsts lietojumprogrammu portāls ir mehānisma izvēles, un katram ir savas sarunas, šifru komplekti un kļūdu režīmi. Neviens no tiem neietver topoloģiju, un topoloģija neizvēlas mehānismu.
Ievietojiet abas asis vienā tabulā, un apjukums kļūst redzams, jo katru režģa šūnu var aizpildīt. Ko tabula nevar izdarīt, ir pateikt, kādu kombināciju piegādāja jūsu piegādātājs, jo produktu nosaukumi abas asis saspiež vienā mārketinga frāzē.
No kurienes nāk kategoriju kļūda
Piegādātāji gadiem ilgi pārdeva „SSL VPN“ kā „IPsec VPN“ pretstatu, kas mehānismu salīdzinājumu padarīja līdzīgu topoloģijas izvēlei. Frāze arī slikti novecojusi pēc saviem noteikumiem, jo pašreizējie risinājumi izmanto atbalstītas TLS versijas, un SSL nosaukums galvenokārt saglabājas kā produktu kategorija.
| Axis | Question it settles | What it cannot tell you |
|---|---|---|
| Topology | Whether users join a gateway or two networks join each other | Which protocol carries the traffic, or how peers prove identity |
| Mechanism | Which protocol suite builds the tunnel and negotiates keys | Whether the endpoints are people, devices or routers |
| Access surface | Whether the client sees a routed network or a set of published applications | Which topology or mechanism is underneath the portal |
| Authentication | What proof each side presents, and to whom | Whether the traffic is later authorized per resource |
No tās pašas saspiešanas izriet divi saistīti mīti. Pirmais ir, ka IPsec nozīmē starp vietnēm; IKEv2 tika projektēts arī klienta un vārtejas attiecībām, tāpēc atsevišķs klēpjdators var pievienoties ar IPsec. Otrais ir, ka uz TLS balstīts produkts nozīmē tikai attālinātu piekļuvi; OpenVPN parasti izmanto satiksmes pārvadāšanai starp divām vietnēm, un tā TLS izmantošana koncentrējas uz vadības un autentifikācijas apmaiņu, nevis pārlūka sesiju.
Noderīgs tests jebkuram aprakstam: ja viena vārda nomaiņa maina gan galapunktus, gan protokolu, teikums sajauc asis. „SSL VPN pret starp vietnēm“ šo testu neiztur, jo pirmais termins nosauc mehānismu saimi, bet otrais – topoloģiju.
Aprakstiet izvietošanu tā, lai to varētu salīdzināt
Uzrakstiet četrus laukus un aizpildiet tos: galapunkti, mehānisms, autentifikācija un piekļuves virsma. Filiāles savienojumu var lasīt kā IKEv2 vārteju pāri starp diviem nosauktiem prefiksiem ar sertifikāta autentifikāciju un bez lietotāja līmeņa portāla. Attālinātās piekļuves pakalpojumu var lasīt kā uz TLS balstītu klientu, kas piešķir adreses katram lietotājam, pieprasa otru faktoru pieteikšanās laikā un publicē tikai iekšējo DNS zonu.
Šie teikumi ir salīdzināmi tā, kā produktu nosaukumi nav. Divus attālinātās piekļuves risinājumus var mērīt pret to pašu lietotāja darbplūsmu un to pašu atsaukšanas ceļu, un divus starpvietņu risinājumus pret to pašu prefiksu sarakstu, satiksmes politiku un kļūdu prasībām. Etiķetes organizē salīdzinājumu; tās to neaizstāj.
Terminoloģijai ir arī publicēts atbalsts. IETF VPN terminoloģijas dokuments atdala vairākus pakalpojumu modeļus, tostarp attālinātu piekļuvi un starp vietnēm, no mehānismiem, ar kuriem tie tiek būvēti, un tā ir tieši tā atšķirība, kas nemitīgi pazūd.
Lasiet sarunoto protokolu, nevis produkta nosaukumu
Etiķete uz kastes nenosaka, par ko vienojās darbojošs tunelis. Jautājiet partnerim tieši TLS pusē un lasiet protokola versiju un šifru, ko radīja rokasspiediens, nevis versiju brošūrā.
openssl s_client -connect vpn.example.net:443 -tls1_3 -briefIPsec vārtejai līdzvērtīgs novērojums nāk no pašas ieviešanas statusa izvades, kas ziņo par izmantotajiem IKE un ESP priekšlikumiem. Jebkurā gadījumā būtība ir tā pati: mehānisma ass ir jālasa no dzīvās sesijas, jo klients un vārteja var vienoties par kaut ko vecāku, nekā gaidīja jebkurš administrators.
ipsec statusall | grep -E "IKE|ESP"Pēc tam paliek jautājumi, uz kuriem neatbild neviena etiķete. Kuras protokola versijas vēl tiek pieņemtas, kā tiek validēta vārtejas identitāte, kāds algoritmu kopums ir atļauts, kas pilnvaro konkrētu lietotāju konkrētam resursam un kas atsauc piekļuvi, kad ierīce tiek pazaudēta. Topoloģijas shēma un mehānisma nosaukums ir šī saraksta sākums, nevis tā aizstājējs.
Tāpēc saglabājiet abas etiķetes, bet izmantojiet tās tam, kas tās ir: īss veids, kā pateikt, kuri galapunkti tiek savienoti un kā tiek būvēts tunelis. Tajā brīdī, kad vienu izmanto otras izslēgšanai, apraksts ir pārstājis kaut ko aprakstīt.