IPv6-adresser ersätter inte din VPN: gå igenom det ursprungliga jobbet

Öppna klientens statussida, se en global IPv6-adress, och frestelsen är att dra slutsatsen att tunneln har blivit valfri. Den sidan visar en adress, inte en krypteringsgräns, inte en privat routingtabell och inte ett åtkomstbeslut. En VPN har vanligtvis tre jobb samtidigt, och IPv6 berör bara det som handlar om att dela knappa adresser. Att gå igenom en enda tjänst från klienten till lyssnaren är det enda sättet att se vilket jobb som överlever ändringen.

Namnge jobbet innan du tar bort verktyget

Folk säger ”VPN” när de menar ett av tre arrangemang, och alla tre misslyckas av olika skäl. Att nå en applikation som publiceras av ett team är ett applikationsåtkomstproblem. Att gå med i en definierad uppsättning privata nätverk så att flera platser kan nå varandra är en routingrelation. Att upprätthålla ett stabilt administrativt överlägg över infrastruktur du inte kontrollerar fullt ut är ett driftarrangemang med en egen adressplan.

IPv6 tar bort ett hinder för adressdelning för det första arrangemanget, och där gör det verklig nytta, eftersom en direkt adress kan ersätta en översättare. För de andra två ändrar det ingenting, eftersom kravet aldrig var adressbrist. Skriv ned vilket av de tre du faktiskt kör innan du rör en konfiguration.

En offentlig adress är inte kryptering

En adress med global räckvidd berättar var en värd kan nås; den säger ingenting om huruvida trafiken som anländer dit är krypterad eller autentiserad. Säkerhetsdiskussionen i RFC 8504 skiljer stödet för IPsec-implementering från det bredare valet mellan IPsec, TLS, SSH och andra angreppssätt, och det är just den skillnaden som försvinner när nåbarhet läses som skydd. En stack som stöder en mekanism har bara bevisat att mekanismen är tillgänglig, aldrig att detta flöde gick igenom den. För IPsec särskilt avgör den förhandlade associationen och trafiken den väljer vad som skyddas, och en adressfamilj är en egenskap hos paketet, inte en policy för det.

Nåbarhet är återigen en separat fråga. En offentlig adress får inte oönskad trafik att anlända, eftersom rutten, brandväggen och lyssnaren har var sin röst, och att ta bort NAT tar bort ett filter, inte alla. Bestäm vilket av de tre tunneln ersatte, om något.

Vad överlägget fortfarande levererar

Ett överlägg förtjänar fortfarande sin plats i tre situationer. Fjärranvändare kan behöva en specifik uppsättning rutter i stället för en applikation, två platser kan behöva ett privat nåbarhetsavtal, och operatörer kan vilja ha adressering som inte ändras när åtkomstleverantören ändras. Ingen av de tre handlar om bristen på IPv4-adresser.

Globala adresser gör inte det underhållsfritt. En städad intern plan håller inte den yttre slutpunkten svarande efter att leverantören ändrar den, och autentisering, återanslutning och namnavuppdateringar behöver fortfarande en ägare. Bestäm hur de återställs innan något stängs av.

Gå igenom tjänsten som blir offentlig

Börja vid värden och lista vad som faktiskt lyssnar, eftersom applikationen du godkände sällan är det enda på maskinen. ss -lntup skriver ut varje TCP- och UDP-lyssnare med sin bindningsadress och lägger till ägarprocessen där dina privilegier tillåter det, vilket visar med en blick om ett administrationsgränssnitt sitter på en jokeradress eller bara på loopback. Upprepa det som ss -6 -lntup om din stack håller IPv6-socklar åtskilda.

Klassificera sedan varje rad efter publik. En applikationsport som bär sin egen autentisering och transportssäkerhet kan vara okej på en offentlig adress, medan ett administrationsgränssnitt, en metrikändpunkt och en databasport vanligtvis inte är det. En godkänd applikation är ett omdöme om just den applikationen, aldrig tillstånd att exponera varje tjänst som delar värden. Bindningsadressen på varje rad berättar om exponeringen redan finns eller skulle skapas av ändringen du planerar.

Två tester, bestäm sedan vad som ska stängas av

Innan du tar bort ett lager, svara på två frågor på papper. För det första, behöver kravet privat routning, det vill säga nåbarhet som en offentlig adress inte innebär och åtkomstleverantören inte erbjuder? För det andra, behöver det en skyddsgräns, det vill säga kryptering och autentisering på ett flöde som annars skulle korsa en obetrodd väg öppet? Om båda svaren är nej för den tjänsten är tunneln en kandidat för borttagning; om något av dem är ja stannar den.

Kör samma test på IPv4 och IPv6 separat på en dual-stack-klient, eftersom skyddad IPv4-trafik inte säger något om IPv6-vägen. En global IPv6-adress på en statussida är inte bevis på läckage, och att den saknas är inte bevis på skydd. Stäng bara av tjänsterna där båda svaren skrevs ned och fortfarande är nej, och notera i ändringsloggen vilken fråga som avgjorde det.