Proč SSL VPN a VPN mezi lokalitami nejsou protiklady
SSL VPN a VPN mezi lokalitami popisují různé osy: kdo se připojuje k síti a jak je tunel postaven. Nazvat obojí zároveň znamená dopustit se chyby kategorie.
Požádejte dva administrátory, aby popsali stejnou VPN, a jeden může odpovědět „SSL VPN“, zatímco druhý řekne „mezi lokalitami“, jako by šlo o konkurenční možnosti v nabídce. Jsou to odpovědi na různé otázky a jejich pojímání jako alternativ vytváří srovnání, která nelze vyřešit. Jeden štítek říká, které koncové body se spojují; druhý říká, co nese provoz mezi nimi. Držte osy oddělené a většina hádky zmizí.
Dva štítky, dvě oddělené otázky
Topologie odpovídá, kdo se k čemu připojuje. Návrh vzdáleného přístupu připojuje jednotlivé uživatele nebo zařízení k bráně, obvykle s identitou na uživatele a fondem adres. Návrh mezi lokalitami spojuje dvě sítě přes brány, takže zajímavou identitou je partnerská brána, nikoli člověk u klávesnice. To jsou různé provozní problémy, od plánování adres po to, kdo může v 2 hodiny ráno odebrat přístup.
Mechanismus odpovídá, jak se tunel staví a autentizuje. IPsec s IKEv2, produkt založený na TLS, který nese IP uvnitř sebe, a portál aplikací obrácený k prohlížeči jsou volby mechanismu a každá má své vyjednávání, šifrové sady a režimy selhání. Žádná z nich nepředpokládá topologii a topologie nevybírá mechanismus.
Dejte obě osy do jedné tabulky a zmatek bude vidět, protože každou buňku mřížky lze vyplnit. Co tabulka nedokáže, je říct vám, kterou kombinaci dodal váš dodavatel, protože názvy produktů slévají obě osy do jedné marketingové fráze.
Odkud chyba kategorie pochází
Dodavatelé roky prodávali „SSL VPN“ jako protiklad „IPsec VPN“, což dělalo srovnání mechanismů jako volbu topologie. Fráze také zestárla špatně i sama o sobě, protože dnešní návrhy používají podporované verze TLS a jméno SSL přežívá hlavně jako kategorie 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 téhož sloučení plynou dva související mýty. První je, že IPsec znamená mezi lokalitami; IKEv2 byl navržen i pro vztahy klient–brána, takže se jednotlivý notebook může připojit přes IPsec. Druhý je, že produkt založený na TLS znamená jen vzdálený přístup; OpenVPN se běžně používá k přenosu provozu mezi dvěma lokalitami a jeho využití TLS se soustředí na výměnu řízení a autentizace, nikoli na relaci prohlížeče.
Užitečný test pro každý popis: pokud výměna jednoho slova změní koncové body i protokol, věta míchá osy. „SSL VPN versus mezi lokalitami“ tímto testem neprojde, protože první termín pojmenovává rodinu mechanismů a druhý topologii.
Popište nasazení tak, aby se dalo srovnávat
Napište čtyři pole a vyplňte je: koncové body, mechanismus, autentizace a povrch přístupu. Propojení pobočky může znít jako pár bran IKEv2 mezi dvěma pojmenovanými prefixy s autentizací certifikátem a bez portálu na úrovni uživatele. Služba vzdáleného přístupu může znít jako klient založený na TLS, který přiděluje adresy na uživatele, vyžaduje při přihlášení druhý faktor a publikuje pouze interní zónu DNS.
Tyto věty jsou srovnatelné způsobem, jakým názvy produktů nejsou. Dva návrhy vzdáleného přístupu lze měřit proti stejnému uživatelskému pracovnímu postupu a stejné cestě odvolání a dva mezilokalitní návrhy proti stejnému seznamu prefixů, politice provozu a požadavkům na selhání. Štítky srovnání organizují; nenahrazují ho.
Terminologie má i publikovanou oporu. Dokument IETF o terminologii VPN odděluje několik modelů služby, včetně vzdáleného přístupu a mezi lokalitami, od mechanismů, jimiž se stavějí, což je přesně ten rozdíl, který se neustále ztrácí.
Čtěte vyjednaný protokol, ne název produktu
Štítek na krabici neurčuje, na čem se běžící tunel dohodl. Zeptejte se partnera přímo, na straně TLS, a čtěte verzi protokolu a šifru, kterou vytvořil handshake, místo verze z brožury.
openssl s_client -connect vpn.example.net:443 -tls1_3 -briefU brány IPsec přichází ekvivalentní pozorování z vlastního stavového výstupu implementace, který hlásí používané návrhy IKE a ESP. Ať tak či onak, pointa je stejná: osu mechanismu je třeba číst ze živé relace, protože klient a brána mohou vyjednat něco staršího, než oba administrátoři očekávali.
ipsec statusall | grep -E "IKE|ESP"Poté zůstávají otázky, na které žádný štítek neodpovídá. Které verze protokolu jsou stále přijímány, jak se ověřuje identita brány, která sada algoritmů je povolena, kdo autorizuje daného uživatele pro daný prostředek a co odebere přístup, když se zařízení ztratí. Topologický diagram a název mechanismu jsou začátek tohoto seznamu, ne jeho náhrada.
Zachovejte tedy oba štítky, ale používejte je pro to, čím jsou: krátký způsob, jak říct, které koncové body se spojují a jak se tunel staví. Ve chvíli, kdy se jeden použije k vyloučení druhého, popis přestal cokoli popisovat.