IPv6-adressen vervangen je VPN niet: doorloop de oorspronkelijke taak

Open de statuspagina van de client, zie een globaal IPv6-adres, en de verleiding is om te concluderen dat de tunnel optioneel is geworden. Die pagina toont een adres, niet een versleutelingsgrens, niet een private routeringstabel en niet een toegangsbeslissing. Een VPN draagt meestal drie taken tegelijk, en IPv6 raakt alleen die over het delen van schaarse adressen. Eén dienst van de client naar de listener doorlopen is de enige manier om te zien welke taak de verandering overleeft.

Benoem de taak voordat je het hulpmiddel verwijdert

Mensen zeggen „de VPN” als ze een van drie regelingen bedoelen, en de drie falen om verschillende redenen. Eén applicatie bereiken die door één team is gepubliceerd is een probleem van applicatietoegang. Toetreden tot een gedefinieerde set private netwerken zodat meerdere locaties elkaar kunnen bereiken is een routeringsrelatie. Een stabiele administratieve laag onderhouden boven infrastructuur die je niet volledig beheert is een operationele regeling met een eigen adresplan.

IPv6 verwijdert een obstakel voor het delen van adressen voor de eerste regeling, en daar doet het echt werk, omdat een direct adres een vertaler kan vervangen. Voor de andere twee verandert het niets, omdat de eis nooit adreschaarste was. Schrijf op welke van de drie je werkelijk draait voordat je een configuratie aanraakt.

Een openbaar adres is geen versleuteling

Een adres met globaal bereik vertelt je waar een host bereikbaar is; het zegt niets over of het verkeer dat daar aankomt versleuteld of geauthenticeerd is. De beveiligingsdiscussie van RFC 8504 scheidt de ondersteuning van de IPsec-implementatie van de bredere keuze tussen IPsec, TLS, SSH en andere benaderingen, en dat is precies het onderscheid dat verdwijnt wanneer bereikbaarheid als bescherming wordt gelezen. Een stack die een mechanisme ondersteunt, heeft alleen bewezen dat het mechanisme beschikbaar is, nooit dat deze stroom erdoorheen ging. Voor IPsec specifiek bepalen de onderhandelde associatie en het verkeer dat zij selecteert wat wordt beschermd, en een adresfamilie is een eigenschap van het pakket, geen beleid ervoor.

Bereikbaarheid is weer een aparte vraag. Een openbaar adres zorgt er niet voor dat ongevraagd verkeer aankomt, want de route, de firewall en de listener hebben elk een stem, en NAT verwijderen verwijdert één filter, niet alle. Bepaal welke van de drie de tunnel verving, als die er was.

Wat de overlay nog levert

Een overlay verdient zijn plek nog steeds in drie situaties. Externe gebruikers hebben misschien een specifieke set routes nodig in plaats van één applicatie, twee locaties hebben misschien een private bereikbaarheidsovereenkomst nodig, en operators willen misschien adressering die niet verandert wanneer de toegangsprovider verandert. Geen van de drie gaat over het tekort aan IPv4-adressen.

Globale adressen maken dat niet onderhoudsvrij. Een netjes intern plan houdt het externe eindpunt niet antwoordend nadat de provider het wijzigt, en authenticatie, herverbinding en naamupdates hebben nog steeds een eigenaar nodig. Bepaal hoe die herstellen voordat er iets wordt uitgeschakeld.

Doorloop de dienst die openbaar wordt

Begin bij de host en lijst op wat werkelijk luistert, want de applicatie die je hebt goedgekeurd is zelden het enige op de machine. ss -lntup drukt elke TCP- en UDP-listener af met het bindadres en voegt het eigenaarsproces toe waar je rechten dat toestaan, wat in één oogopslag laat zien of een beheerinterface op een jokeradres of alleen op loopback zit. Herhaal het als ss -6 -lntup als je stack IPv6-sockets gescheiden houdt.

Classificeer daarna elke regel naar publiek. Een applicatiepoort met eigen authenticatie en transportbeveiliging kan prima zijn op een openbaar adres, terwijl een beheerinterface, een metriek-eindpunt en een databasepoort dat meestal niet zijn. Eén goedgekeurde applicatie is een oordeel over die applicatie alleen, nooit toestemming om elke dienst die de host deelt bloot te stellen. Het bindadres op elke regel vertelt je of de blootstelling al bestaat of zou worden gecreëerd door de wijziging die je plant.

Twee tests, dan bepalen wat je uitschakelt

Voordat je een laag verwijdert, beantwoord twee vragen op papier. Ten eerste, heeft de eis private routering nodig, dat wil zeggen bereikbaarheid die een openbaar adres niet impliceert en de toegangsprovider niet biedt? Ten tweede, heeft het een beschermingsgrens nodig, dat wil zeggen versleuteling en authenticatie op een stroom die anders een onbetrouwbaar pad openlijk zou kruisen? Als beide antwoorden nee zijn voor die dienst, is de tunnel een kandidaat voor verwijdering; als een van beide ja is, blijft hij.

Voer dezelfde test apart uit op IPv4 en IPv6 op een dual-stackclient, want beschermd IPv4-verkeer zegt niets over het IPv6-pad. Een globaal IPv6-adres op een statuspagina is geen bewijs van een lek, en het ontbreken ervan is geen bewijs van bescherming. Schakel alleen de diensten uit waarvan beide antwoorden zijn opgeschreven en nog steeds nee zijn, en noteer in het wijzigingsregister welke vraag dat bepaalde.