Dlaczego SSL VPN i VPN między witrynami nie są przeciwieństwami
SSL VPN i VPN między witrynami opisują różne osie: kto dołącza do sieci i jak budowany jest tunel. Nazywanie obu jednocześnie to błąd kategorii.
Poproś dwóch administratorów o opisanie tej samej VPN: jeden może odpowiedzieć „SSL VPN”, a drugi powiedzieć „między witrynami”, jakby były to rywalizujące opcje w menu. To odpowiedzi na różne pytania, a traktowanie ich jako alternatyw daje porównania, których nie da się rozstrzygnąć. Jedna etykieta mówi, które punkty końcowe są łączone; druga mówi, co przenosi ruch między nimi. Trzymaj osie osobno, a większość sporu znika.
Dwie etykiety, dwa osobne pytania
Topologia odpowiada, kto z czym się łączy. Projekt dostępu zdalnego podłącza pojedynczych użytkowników lub urządzenia do bramy, zwykle z tożsamością na użytkownika i pulą adresów. Projekt między witrynami łączy dwie sieci przez bramy, więc interesującą tożsamością jest brama partnerska, a nie osoba przy klawiaturze. To różne problemy operacyjne, od planowania adresów po to, kto może odebrać dostęp o 2 w nocy.
Mechanizm odpowiada, jak tunel jest budowany i uwierzytelniany. IPsec z IKEv2, produkt oparty na TLS, który przenosi IP w sobie, oraz portal aplikacji zwrócony do przeglądarki to wybory mechanizmu, a każdy ma własne negocjacje, zestawy szyfrów i tryby awarii. Żaden z nich nie implikuje topologii, a topologia nie wybiera mechanizmu.
Umieść dwie osie w jednej tabeli, a zamieszanie stanie się widoczne, bo każdą komórkę siatki można wypełnić. Tabela nie może powiedzieć, którą kombinację dostarczył twój dostawca, ponieważ nazwy produktów spłaszczają obie osie do jednego zwrotu marketingowego.
Skąd bierze się błąd kategorii
Dostawcy przez lata sprzedawali „SSL VPN” jako przeciwieństwo „IPsec VPN”, przez co porównanie mechanizmów wyglądało jak wybór topologii. Sam zwrot też źle się zestarzał na własnych warunkach, bo dzisiejsze projekty używają obsługiwanych wersji TLS, a nazwa SSL przetrwała głównie jako kategoria produktu.
| 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 |
Z tego samego spłaszczenia wynikają dwa powiązane mity. Pierwszy mówi, że IPsec oznacza między witrynami; IKEv2 zaprojektowano także dla relacji klient–brama, więc pojedynczy laptop może dołączyć przez IPsec. Drugi mówi, że produkt oparty na TLS oznacza tylko dostęp zdalny; OpenVPN jest rutynowo używany do przenoszenia ruchu między dwiema witrynami, a jego użycie TLS koncentruje się na wymianie sterowania i uwierzytelniania, a nie na sesji przeglądarki.
Przydatny test każdego opisu: jeśli zamiana jednego słowa zmienia zarówno punkty końcowe, jak i protokół, zdanie miesza osie. „SSL VPN kontra między witrynami” nie przechodzi tego testu, bo pierwszy termin nazywa rodzinę mechanizmów, a drugi topologię.
Opisz wdrożenie tak, aby można je było porównać
Napisz cztery pola i wypełnij je: punkty końcowe, mechanizm, uwierzytelnianie i powierzchnia dostępu. Łącze oddziału można czytać jako parę bram IKEv2 między dwoma nazwanymi prefiksami z uwierzytelnianiem certyfikatem i bez portalu na poziomie użytkownika. Usługę dostępu zdalnego można czytać jako klienta opartego na TLS, który przydziela adresy na użytkownika, wymaga drugiego czynnika przy logowaniu i publikuje tylko wewnętrzną strefę DNS.
Te zdania są porównywalne w sposób, w jaki nazwy produktów nie są. Dwa projekty dostępu zdalnego można mierzyć wobec tego samego przepływu pracy użytkownika i tej samej ścieżki odbioru, a dwa projekty między witrynami wobec tej samej listy prefiksów, polityki ruchu i wymagań awaryjnych. Etykiety organizują porównanie; nie zastępują go.
Terminologia ma też opublikowaną kotwicę. Dokument IETF o terminologii VPN oddziela kilka modeli usług, w tym dostęp zdalny i między witrynami, od mechanizmów, za pomocą których są budowane, i to jest dokładnie ta różnica, która ciągle się gubi.
Czytaj wynegocjowany protokół, nie nazwę produktu
Etykieta na pudełku nie ustala, na co zgodził się działający tunel. Zapytaj partnera bezpośrednio, po stronie TLS, i odczytaj wersję protokołu oraz szyfr wytworzone przez uzgadnianie, a nie wersję z broszury.
openssl s_client -connect vpn.example.net:443 -tls1_3 -briefDla bramy IPsec równoważna obserwacja pochodzi z własnego wyjścia statusu implementacji, które raportuje używane propozycje IKE i ESP. Tak czy inaczej, sedno jest to samo: oś mechanizmu trzeba odczytać z żywej sesji, bo klient i brama mogą wynegocjować coś starszego, niż oczekiwał którykolwiek administrator.
ipsec statusall | grep -E "IKE|ESP"Potem zostają pytania, na które żadna etykieta nie odpowiada. Które wersje protokołu są jeszcze akceptowane, jak walidowana jest tożsamość bramy, jaki zestaw algorytmów jest dozwolony, kto autoryzuje danego użytkownika do danego zasobu i co odbiera dostęp, gdy urządzenie zginie. Diagram topologii i nazwa mechanizmu to początek tej listy, a nie jej zamiennik.
Zachowaj więc dwie etykiety, ale używaj ich do tego, czym są: krótki sposób powiedzenia, które punkty końcowe są łączone i jak budowany jest tunel. W chwili, gdy jedna służy do wykluczenia drugiej, opis przestał cokolwiek opisywać.