Az IPv6-címek nem váltják le a VPN-t: járják végig az eredeti feladatot

Nyissák meg a kliens állapotoldalát, lássanak egy globális IPv6-címet, és a kísértés, hogy arra következtessenek: az alagút mostantól választható. Az az oldal egy címet mutat, nem titkosítási határt, nem privát útválasztási táblát és nem hozzáférési döntést. A VPN általában három feladatot lát el egyszerre, és az IPv6 csak azt érinti, amely a szűkös címek megosztásáról szól. Egyetlen szolgáltatás végigjárása a klienstől a fogadóig az egyetlen módja annak, hogy lássák, melyik feladat éli túl a változást.

Nevezzék meg a feladatot, mielőtt eltávolítják az eszközt

Az emberek „a VPN”-t mondanak, amikor három elrendezés egyikére gondolnak, és mindhárom más-más okból bukik el. Egy csapat által közzétett alkalmazás elérése alkalmazáshozzáférési probléma. Privát hálózatok meghatározott halmazához csatlakozni, hogy több hely elérhesse egymást, útválasztási viszony. Stabil adminisztratív réteget fenntartani olyan infrastruktúra fölött, amelyet nem ellenőriznek teljesen, saját címtervvel rendelkező üzemeltetési elrendezés.

Az IPv6 a címek megosztásának akadályát szünteti meg az első elrendezésnél, és ott valódi munkát végez, mert egy közvetlen cím helyettesíthet egy fordítót. A másik kettőnél semmit sem változtat, mert a követelmény soha nem a címhiány volt. Írják le, melyiket futtatják valójában a három közül, mielőtt hozzányúlnak egy konfigurációhoz.

A nyilvános cím nem titkosítás

Egy globális terjedelmű cím megmondja, honnan érhető el egy gazdagép; semmit sem mond arról, hogy az oda érkező forgalom titkosított-e vagy hitelesített. Az RFC 8504 biztonsági vitája elválasztja az IPsec-implementáció támogatását az IPsec, a TLS, az SSH és más megközelítések közötti szélesebb választástól, és éppen ez az a különbség, amely eltűnik, amikor az elérhetőséget védelemként olvassák. Egy mechanizmust támogató verem csak azt bizonyította, hogy a mechanizmus elérhető, soha azt, hogy ez a folyam átment rajta. Az IPsec esetében konkrétan a kialkudott társítás és az általa kiválasztott forgalom dönti el, mi védett, és a címcsalád a csomag tulajdonsága, nem pedig szabály számára.

Az elérhetőség megint külön kérdés. Egy nyilvános cím nem teszi elérhetővé a kéretlen forgalmat, mert az útvonalnak, a tűzfalmak és a fogadónak egyaránt van szavazata, és a NAT eltávolítása egy szűrőt távolít el, nem mindet. Döntsék el, melyiket helyettesítette az alagút a három közül, ha egyáltalán valamelyiket.

Mit nyújt még a fedőréteg

A fedőréteg még három helyzetben érdemli ki a helyét. A távoli felhasználóknak lehet, hogy egy adott útvonalkészletre van szükségük egyetlen alkalmazás helyett, két helynek lehet, hogy privát elérhetőségi megállapodásra van szüksége, és az üzemeltetők olyan címzést akarhatnak, amely nem változik, amikor a hozzáférési szolgáltató változik. Egyik sem az IPv4-címek szűkösségéről szól.

A globális címek nem teszik ezt karbantartásmentessé. Egy rendezett belső terv nem tartja válaszolóképesen a külső végpontot, miután a szolgáltató megváltoztatja, és a hitelesítésnek, az újracsatlakozásnak és a névfrissítéseknek továbbra is kell egy felelős. Döntsék el, hogyan állnak helyre ezek, mielőtt bármit kikapcsolnak.

Járják végig a szolgáltatást, amely nyilvánossá válik

A gazdagépnél kezdjék, és sorolják fel, mi hallgat valójában, mert az általuk jóváhagyott alkalmazás ritkán az egyetlen dolog a gépen. ss -lntup kiír minden TCP- és UDP-fogadót a kötési címével, és hozzáadja a tulajdonos folyamatot, ahol jogosultságaik engedik, ami egy pillantásra megmutatja, hogy egy felügyeleti felület helyettesítő címen vagy csak loopbacken ül-e. Ismételjék meg ss -6 -lntup formában, ha a verem külön tartja az IPv6-socketeket.

Ezután sorolják be az egyes sorokat a közönség szerint. Egy saját hitelesítéssel és átviteli biztonsággal rendelkező alkalmazásport rendben lehet egy nyilvános címen, míg egy adminisztratív felület, egy metrikavégpont és egy adatbázisport általában nem. Egy jóváhagyott alkalmazás csak arról az alkalmazásról szóló ítélet, soha nem engedély a gazdagépet megosztó minden szolgáltatás kitettségére. Az egyes sorok kötési címe megmondja, hogy a kitettség már létezik-e, vagy a tervezett változás hozná létre.

Két teszt, aztán döntsék el, mit kapcsoljanak ki

Mielőtt eltávolítanak egy réteget, válaszoljanak papíron két kérdésre. Először, szüksége van-e a követelménynek privát útválasztásra, vagyis olyan elérhetőségre, amelyet egy nyilvános cím nem foglal magában, és a hozzáférési szolgáltató nem kínál? Másodszor, szüksége van-e védelmi határra, vagyis titkosításra és hitelesítésre egy olyan folyamon, amely egyébként nyíltan kelne át egy nem megbízható úton? Ha mindkét válasz nem arra a szolgáltatásra, az alagút eltávolítási jelölt; ha bármelyik igen, marad.

Futtassák ugyanezt a tesztet IPv4-en és IPv6-on külön, egy kettős veremű kliensen, mert a védett IPv4-forgalom semmit sem mond az IPv6-útról. Egy globális IPv6-cím az állapotoldalon nem szivárgás bizonyítéka, és a hiánya nem védelem bizonyítéka. Csak azokat a szolgáltatásokat kapcsolják ki, amelyeknél mindkét választ leírták, és még mindig nem, és jegyezzék fel a változási naplóba, melyik kérdés döntött.