A VPN titkosítás magyarázata: IPSec vs SSL

IPSec vs SSL

Rengeteg más cikk áll rendelkezésre, amelyek összehasonlítják és összehasonlítják az IPSec és az SSL VPN-eket egy hálózati adminisztrátor szempontjából, akinek ki kell állítania őket. Ez a cikk azonban megvizsgálja hogyan használják a nagy kereskedelmi VPN szolgáltatók az SSL-t és az IPSec-et fogyasztói szolgáltatásukban, amelyek célja az internethez való hozzáférés, és nem a vállalati hálózat elérése.

A használt VPN-protokollok Az IPSec titkosítás magában foglalja az L2TP, IKEv2 és SSTP fájlokat. Az OpenVPN a legnépszerűbb protokoll, amely SSL titkosítást használ, különösen az OpenSSL könyvtár. Az SSL-t néhány böngésző alapú VPN-ben is használják.

Ez a cikk összehasonlítja és ellentmond az IPSec és az SSL titkosításnak a VPN végfelhasználói szempontból. Ha a két protokoll alaposabb magyarázatát szeretné megismerni, olvassa el az általános titkosítási típusokról szóló részletes útmutatót.

A VPN titkosítás alapjai

A VPN-titkosítás oly módon olvassa be az internetes forgalom tartalmát, hogy csak a megfelelő kulcs használatával lehet visszafejteni (visszafejteni). A kimenő adatokat a készülék elhagyása előtt titkosítja. Ezután elküldi a VPN szervernek, amely a megfelelő kulcsmal dekódolja az adatokat. Innentől az adatokat továbbítják a rendeltetési helyére, például egy weboldalra. A titkosítás megakadályozza, hogy bárki, aki véletlenül elfogja az adatokat közted és a VPN szerver között - internetszolgáltatók, kormányzati ügynökségek, wifi hackerek stb. - képesek legyenek megfejteni a tartalmat..

A bejövő forgalom ugyanazon a folyamaton megy végbe. Ha az adatok egy webhelyről származnak, akkor először a VPN szerverre kerülnek. A VPN-kiszolgáló titkosítja az adatokat, majd elküldi azokat az eszközére. Ezután a készülék dekódolja az adatokat, így normál módon megnézheti a weboldalt.

Mindez biztosítja, hogy a VPN-felhasználók internetes adatai privát módon maradjanak és minden illetéktelen fél kezétől kerüljenek ki.

A különféle típusú titkosítások közötti különbségek a következők:

  • Titkosítási erősség, vagy az a módszer, ameddig az adatok beolvadnak
  • A titkosítási kulcsok kezelése és cseréje
  • Milyen interfészeket, protokollokat és portokat használnak
  • Milyen OSI rétegeken futnak
  • Könnyű telepítés
  • Teljesítmény (olvasás: sebesség)

Biztonság

Röviden: Enyhén az SSL mellett.

Az IPSec kapcsolatokhoz előzetesen megosztott kulcs szükséges, hogy létezzenek mind az ügyfélen, mind a kiszolgálón, hogy titkosítsák és forgalmat küldhessenek egymásnak. Ennek a kulcsnak a cseréje lehetőséget kínál a támadónak az előre megosztott kulcs feltörésére vagy elfogására.

Az SSL VPN-knek nem merül fel ez a probléma, mert nyilvános kulcsú kriptográfiát használnak kézfogás megbeszélésére és titkosítási kulcsok biztonságos cseréjére. A TLS / SSL azonban hosszú listát tartalmaz a saját sebezhetőségéről, mint például a Heartbleed.

Néhány SSL VPN engedélyezi a nem megbízható, önaláírt tanúsítványokat, és nem hitelesíti az ügyfeleket. Ez különösen a „kliens nélküli” SSL VPN böngésző kiterjesztéseknél. Ezek a VPN-ek, amelyek lehetővé teszik, hogy bárki csatlakozhasson bármilyen gépről, sebezhetők a közepén lévő (MITM) támadásokkal szemben. Ez a helyzet azonban a legtöbb natív OpenVPN ügyfél esetében.

Az SSL rendszerint gyakoribb javításokat igényel, hogy naprakészek legyenek, mind a szerver, mind az ügyfél számára.

Az IPSec-alapú VPN-protokollok nyílt forráskódjának hiánya aggodalomra adhat okot az emberek számára, akik óvakodnak a kormányzati kémektől és snooperektől. 2013-ban Edward Snowden feltárta az Egyesült Államok Nemzeti Biztonsági Ügynökségének Bullrun programját, amely aktívan megkísérelte „biztonsági réseket beilleszteni a célzottan használt titkosítási rendszerekbe, informatikai rendszerekbe, hálózatokba és a végpont kommunikációs eszközökbe.” Az NSA állítólag az IPSec-t célozta meg, hogy hátsó ajtókat és oldalsó csatornákat hozzon létre a hackerek kihasználhatnák.

Végül az erős biztonság inkább a képzett és figyelmes hálózati rendszergazdák eredménye, mint a protokoll választása.

Tűzfal átjárása

Röviden: Az SSL-alapú VPN-k általában jobbak a tűzfalak megkerülésére.

A NAT tűzfalak gyakran léteznek wifi útválasztókon és más hálózati hardvereken. A fenyegetésekkel szembeni védelem érdekében minden ismeretlen internetes forgalmat eldobnak, amely portszám nélküli adatcsomagokat is tartalmaz. A titkosított IPSec-csomagok (ESP-csomagok) alapértelmezés szerint nem rendelkeznek portszámmal, azaz elkaphatnak a NAT tűzfalakba. Ez megakadályozhatja az IPSec VPN-k működését.

IPSec esp.svg

Ennek elkerülésére sok IPSec VPN beágyazza az ESP csomagokat az UDP csomagokba, így az adatokhoz UDP portszámot rendelnek, általában UDP 4500. Míg ez megoldja a NAT átjárási problémát, a hálózati tűzfal esetleg nem engedélyezi a csomagok használatát ezen a porton. A szállodák, repülőterek és más helyek hálózati rendszergazdái csak néhány szükséges protokollon engedélyezhetnek forgalmat, és az UDP 4500 nem lehet köztük.

Az SSL-forgalom áthaladhat a 443-as porton, amelyet a legtöbb eszköz felismer a biztonságos HTTPS-forgalomhoz használt portként. Szinte minden hálózat engedélyezi a HTTPS forgalmat a 443-as porton, tehát feltételezhetjük, hogy nyitva van. Az OpenVPN alapértelmezés szerint az 1194-es portot használja az UDP-forgalomhoz, de továbbküldhető akár UDP, akár TCP portokon keresztül, beleértve a 443 TCP portot. Az SSL sokkal hasznosabb a tűzfalak és a cenzúra más formáinak megkerülésére amelyek blokkolják a forgalmat a kikötők alapján.

Sebesség és megbízhatóság

Röviden: Mindkettő meglehetősen gyors, de az IKEv2 / IPSec a csatlakozást a leggyorsabban tárgyalja.

A legtöbb IPSec-alapú VPN-protokoll hosszabb időt vesz igénybe a kapcsolat megbeszélésekor, mint az SSL-alapú protokollok, de ez az eset nem az IKEv2 / IPSec esetében.

Az IKEv2 egy IPSec-alapú VPN-protokoll, amely már több mint egy évtizede működik, de most a VPN-szolgáltatók körében egyre inkább megjelenik. A telepítés elősegíti az a képesség, hogy gyorsan és megbízhatóan újracsatlakozzon a VPN-kapcsolat megszakadásakor. Ez különösen akkor hasznos, ha a mobil iOS és az Android ügyfelek nem rendelkeznek megbízható kapcsolatokkal, vagy azoknak, akik gyakran váltanak a mobil adat és a wifi között..

Ami a tényleges teljesítményt illeti, ez egy dobás. Mindkét oldal érveit láttuk. Egy blogbejegyzésben az NordVPN kijelenti, hogy az IKEv2 / IPSec gyorsabb átviteli sebességet tud nyújtani, mint a riválisok, mint az OpenVPN. Mindkét protokoll általában a 128 bites vagy a 256 bites AES titkosítást használja.

Az extra UDP réteg, amelyet sok szolgáltató az IPSec forgalomra helyez a tűzfalak áthaladásának elősegítése érdekében, további fölényt jelent, ami azt jelenti, hogy további erőforrásokra van szükség a feldolgozáshoz. De a legtöbb ember nem fog észrevenni a különbséget.

A legtöbb fogyasztói VPN-en az átvitelt nagyrészt a szerver és a hálózat torlódása határozza meg, nem pedig a VPN-protokoll.

Lásd még: Leggyorsabb VPN-ek

Egyszerű használat

Röviden: Az IPSec sokkal univerzálisabb, de a VPN-szolgáltatók alkalmazását használó felhasználók többsége nem fog észrevenni hatalmas különbséget.

Az IKEv2, SSTP és L2TP beépített IPSec-alapú VPN-protokollok a legtöbb fő operációs rendszeren, ami azt jelenti, hogy az induláshoz és futtatáshoz szükségtelen külön alkalmazás. A fogyasztói VPN-ek legtöbb felhasználója továbbra is a szolgáltató alkalmazását fogja használni, hogy kapcsolatba kerüljön.

cyberhost protokollok

Az SSL alapértelmezés szerint a legtöbb böngészőben működik, de általában az OpenVPN használatához harmadik féltől származó alkalmazásra van szükség. Ezt ismét a VPN-szolgáltató alkalmazza.

Tapasztalataink szerint az IKEv2 a végfelhasználó szempontjából inkább zökkenőmentes élményt nyújt, mint az OpenVPN. Ez nagyrészt annak köszönhető, hogy az IKEv2 gyorsan csatlakozik és kezeli a megszakításokat. Ennek ellenére az OpenVPN sokkal sokoldalúbb, és jobban megfelelhet azoknak a felhasználóknak, akik az IKEv2-rel nem tudják elvégezni azt, amit akarnak..

Amikor az olyan vállalati VPN-ket érinti, amelyek nem az internethez, hanem a vállalati hálózathoz biztosítanak hozzáférést, az általános egyetértés abban áll, hogy az IPSec inkább az egyes helyek közötti VPN-ek, az SSL pedig jobb a távoli eléréshez. Ennek oka az, hogy az IPSec az OSI modell hálózati rétegén működik, amely teljes hozzáférést biztosít a felhasználónak a vállalati hálózathoz, az alkalmazástól függetlenül. Nehezebb korlátozni a hozzáférést az egyes erőforrásokhoz. Az SSL VPN-k ugyanakkor lehetővé teszik a vállalkozások számára, hogy granulált szinten távoli hozzáférést vezessenek az egyes alkalmazásokhoz.

Internetprotocolsecurity

A VPN-ket üzemeltető hálózati rendszergazdák sokkal könnyebben és kevésbé időigényesen találják meg az ügyfélkezelést az SSL-rel, mint az IPSec-rel..

IPSec vs SSL VPN: következtetés

Mindent összevetve, mindkét lehetőséggel rendelkező VPN-felhasználók számára javasoljuk az IKEv2 / IPSec használatát, majd az OpenVPN-hez fordulást, ha bármilyen kérdés felbukkan. Az az sebesség, amellyel az IKEv2 képes egyeztetni és kapcsolatot létesíteni, kézzelfoghatóbb életminőség-javulást kínál az átlagos, mindennapi VPN-felhasználók számára, miközben összehasonlítható biztonságot és sebességet kínál, de előfordulhat, hogy nem minden esetben működik.

Az OpenVPN / SSL egészen a közelmúltig tartotta a legjobb VPN kombinációt a fogyasztói VPN-k legtöbb felhasználójának. Az OpenVPN, amely az OpenSSL könyvtárat használja a titkosításhoz és a hitelesítéshez, meglehetősen gyors, nagyon biztonságos, nyílt forrású, és képes átjárni a NAT tűzfalakat. Támogathatja az UDP vagy a TCP protokollt.

Az IKEv2 / IPSec új kihívót mutat be az OpenVPN számára, javítva az L2TP és más IPSec-alapú protokollokat, gyorsabb kapcsolatokkal, nagyobb stabilitással és beépített támogatással a legtöbb újabb fogyasztói eszközön.

Az SSL és az IPSec egyaránt erős biztonsági törzskönyveket büszkélkedhet, összehasonlítható átviteli sebességgel, biztonsággal és könnyű kezelhetőséggel a legtöbb VPN-szolgáltatás ügyfelének.

Soufiane Hamdaoui, a CC BY-SA 3.0 alapján engedélyezett „IPsec in netwerklaag”

Brayan Jackson Administrator
Sorry! The Author has not filled his profile.
follow me

About the author

Leave a Reply

Your email address will not be published. Required fields are marked *

− 1 = 2

Adblock
detector