Miért nem ellentétei egymásnak az SSL VPN és a helyszín-helyszín VPN
Az SSL VPN és a helyszín-helyszín VPN különböző tengelyeket ír le: ki csatlakozik a hálózathoz, és hogyan épül az alagút. A kettőt együtt nevezni kategóriahiba.
Kérjen meg két rendszergazdát, hogy ugyanazt a VPN-t írja le, és az egyik talán „SSL VPN”-t válaszol, míg a másik „helyszín-helyszín”-t mond, mintha a kettő versengő lehetőség lenne egy menüben. Ezek különböző kérdésekre adott válaszok, és alternatívaként kezelésük olyan összehasonlításokat szül, amelyek nem oldhatók fel. Az egyik címke azt mondja meg, mely végpontok kapcsolódnak össze; a másik azt, hogy mi viszi a forgalmat közöttük. Tartsa külön a tengelyeket, és a vita nagy része eltűnik.
Két címke, két külön kérdés
A topológia arra válaszol, ki kapcsolódik mihez. A távoli hozzáférés terve egyedi felhasználókat vagy eszközöket kapcsol egy átjáróhoz, általában felhasználónkénti identitással és címpool-lal. A helyszín-helyszín terv két hálózatot köt össze átjárókon keresztül, így az érdekes identitás a társ-átjáró, nem pedig a billentyűzet előtti személy. Ezek különböző üzemeltetési problémák, a címtervezéstől addig, hogy ki vonhatja vissza a hozzáférést hajnali 2-kor.
A mechanizmus arra válaszol, hogyan épül és hitelesítődik az alagút. Az IPsec IKEv2-vel, egy TLS-alapú termék, amely IP-t hordoz magában, és egy böngésző felé forduló alkalmazásportál mechanizmusválasztások, és mindegyiknek megvan a maga egyeztetése, titkosítócsomagja és hibaállapota. Egyik sem feltételez topológiát, és a topológia nem választ mechanizmust.
Tegye a két tengelyt egy táblázatba, és a zavar láthatóvá válik, mert a rács minden cellája kitölthető. Amit a rács nem tud, az az, hogy megmondja, melyik kombinációt szállította a szállítója, mert a terméknevek mindkét tengelyt egyetlen marketingmondatba sűrítik.
Honnan ered a kategóriahiba
A szállítók évekig „SSL VPN”-ként adták el az „IPsec VPN” ellentéteként, amitől a mechanizmusok összehasonlítása topológiaválasztásnak látszott. A kifejezés a saját feltételei szerint is rosszul öregedett, mert a mai tervek támogatott TLS-verziókat használnak, és az SSL név főleg termékkategóriaként maradt fenn.
| 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 |
Ugyanebből az összesűrítésből két rokon mítosz következik. Az első, hogy az IPsec helyszín-helyszín kapcsolatot jelent; az IKEv2-t kliens–átjáró viszonyokra is tervezték, így egyetlen laptop is csatlakozhat IPsec-kel. A második, hogy a TLS-alapú termék csak távoli hozzáférést jelent; OpenVPN rendszeresen használatos két helyszín közötti forgalom továbbítására, és TLS-használata a vezérlési és hitelesítési csere köré összpontosul, nem pedig egy böngésző-munkamenetbe.
Hasznos próba bármely leíráshoz: ha egy szó cseréje mind a végpontokat, mind a protokollt megváltoztatja, a mondat keveri a tengelyeket. Az „SSL VPN szemben a helyszín-helyszín”-nel megbukik ezen a próbán, mert az első kifejezés mechanizmuscsaládot, a második topológiát nevez meg.
Írjon le egy telepítést úgy, hogy összehasonlítható legyen
Írjon négy mezőt, és töltse ki őket: végpontok, mechanizmus, hitelesítés és hozzáférési felület. Egy fióktelep-kapcsolat úgy olvasható, mint két megnevezett előtag közötti IKEv2-átjárópár tanúsítványos hitelesítéssel és felhasználói szintű portál nélkül. Egy távoli hozzáférési szolgáltatás úgy olvasható, mint TLS-alapú kliens, amely felhasználónként oszt címeket, bejelentkezéskor második tényezőt kér, és csak belső DNS-zónát tesz közzé.
Ezek a mondatok összehasonlíthatók oly módon, ahogy a terméknevek nem. Két távoli hozzáférési terv mérhető ugyanahhoz a felhasználói munkafolyamathoz és ugyanahhoz a visszavonási útvonalhoz, két helyszínek közötti terv pedig ugyanahhoz az előtaglistához, forgalompolitikához és hiba követelményeihez. A címkék megszervezik az összehasonlítást; nem helyettesítik azt.
A terminológiának közzétett horgonya is van. Az IETF VPN-terminológiai dokumentuma több szolgáltatási modellt, köztük a távoli hozzáférést és a helyszín-helyszín kapcsolatot, elválaszt azoktól a mechanizmusoktól, amelyekkel épülnek, és pontosan ez a megkülönböztetés vész el újra és újra.
A kialkudott protokollt olvassa, ne a termék nevét
A dobozon lévő címke nem állapítja meg, miben egyezett meg egy futó alagút. Kérdezze meg közvetlenül a partnert a TLS-oldalon, és olvassa le a kézfogás által létrehozott protokollverziót és titkosítást a prospektusban szereplő verzió helyett.
openssl s_client -connect vpn.example.net:443 -tls1_3 -briefEgy IPsec-átjáró esetében a megfelelő megfigyelés a megvalósítás saját állapotkimenetéből származik, amely jelenti a használt IKE- és ESP-javaslatokat. Akárhogy is, a lényeg ugyanaz: a mechanizmustengelyt az élő munkamenetből kell leolvasni, mert a kliens és az átjáró lealkudhat valami olyasmire, ami régebbi annál, mint amit bármelyik rendszergazda várt.
ipsec statusall | grep -E "IKE|ESP"Ezután azok a kérdések maradnak, amelyekre egyetlen címke sem válaszol. Mely protokollverziókat fogadják még el, hogyan validálják az átjáró identitását, mely algoritmuskészlet engedélyezett, ki jogosít fel egy adott felhasználót egy adott erőforrásra, és mi vonja vissza a hozzáférést, ha egy eszköz elveszik. Egy topológiarajz és egy mechanizmusnév e lista kezdete, nem helyettesítője.
Tartsa meg tehát a két címkét, de arra használja őket, amik: rövid módja annak, hogy megmondjuk, mely végpontok kapcsolódnak össze, és hogyan épül az alagút. Abban a pillanatban, amikor az egyiket a másik kizárására használják, a leírás megszűnt bármit leírni.