IPv6 ULA i en VPN: privat adressering, inte integritet

Adresser som ser privata ut är inte privata i den mening de flesta menar, och IPv6:s unika lokala adressering är det tydligaste fallet. Ett ULA-prefix ger en VPN en stabil intern plan för resurserna bakom den. Det krypterar ingenting, autentiserar inte en peer och avgör inte vilka tjänster en klient kan nå. Att behandla prefixet som en säkerhetskontroll är felet som den här artikeln ska ta bort.

Vad prefixet faktiskt ger

RFC 4193 reserverar fc00::/7 för lokal användning, där L-biten skiljer lokalt tilldelat utrymme från den reserverade formen. I praktiken innebär det att det är fd00::/8 du genererar. Specifikationen definierar också hur det 40-bitars globala ID:t ska härledas, så att oberoende platser inte råkar välja samma prefix. Det utrymmet är utformat för att hållas utanför det publika internet, vilket är en routingegenskap och inte ett skydd.

Inom en plats är den vanliga uppdelningen ett /48 globalt ID indelat i subnät: ett för tunnelklienter, ett för serversidan och ett för varje fjärr-LAN. Den strukturen är hela nyttan, och det är en adresseringsnytta. Varje paket behöver fortfarande en rutt och fortfarande en policy som tillåter det.

Att förväxla prefixet med en tunnel är hur en design till slut dokumenterar fd00-adresser och antar att trafiken mellan dem är skyddad. Det är den inte, om inte något annat står för skyddet.

Varför kopiering av exemplets prefix gör ont

Varje guide använder ett lättihågkommet prefix, och varje läsare som kopierar det ärver samma kollisionsrisk. Två platser som senare kopplas samman via en plats-till-plats-tunnel med identiska intervall frambringar exakt den tvetydighet som är känd från överlappande privata IPv4-utrymmen. Ingen av sidorna är fel i sig, och det sammanslagna nätet har inget sätt att veta vilken destination som avses.

Att generera det globala ID:t enligt den dokumenterade processen tar en minut och tar bort frågan. Notera prefixet, genereringsindata och datum bredvid adressplanen.

Risken är inte teoretisk för den som slår samman nätverk efter ett förvärv eller kopplar ihop två laboratorier över en VPN. Den är inte heller brådskande för en enda plats, och därför skjuts den upp tills sammanslagningen redan är planerad.

Omfattning och åtkomst är separata frågor

ULA är inte avsett för vanlig globalt routad internetadressering. Det gör inte varje värd som använder det betrodd, och det gör inte dessa värdar oåtkomliga från andra anslutna privata nätverk. Brandväggar och applikationsbehörigheter avgör fortfarande vad en peer får använda, och tunneln levererar fortfarande den autentisering den konfigurerades med.

En internetutgång behöver sin egen IPv6-utgångsdesign. Att tilldela en ULA-adress till en klient skapar inte åtkomst till godtyckliga globala destinationer, och en klient som får en bör inte förväntas surfa på det publika internet via den.

Två platser med olika prefix behöver fortfarande returrutter för varandras intervall, och båda brandväggarna behöver matchande regler. Inget av detta följer av adressfamiljen. Det som följer är dokumentationsarbete: en tabell över prefix och de system som får svara på var och en av dem.

Kontrollera planen i båda ändar

Bekräfta att prefixet visas där du tror att det gör det, och bekräfta sedan att en destination faktiskt är nåbar via det.

ip -6 address show
ip -6 route show
ping -6 -c 3 fd12:3456:789a:1::1

Adresslistan visar vilket gränssnitt som har vilket subnät, och en klient som fick fel visar det vanligtvis här. Ruttlistan visar om det avlägsna prefixet har en väg genom tunneln i stället för att slängas. Testet svarar på den enda fråga som betyder något: om ett paket tar resan fram och tillbaka.

Upprepa kontrollen efter en återanslutning, eftersom en klient som behåller adressen men tappar rutten ger en anslutning som ser uppe ut och inte vidarebefordrar något. Adressen är den enkla delen, och rutten är det som försvinner. Spara båda utskrifterna bredvid namnet på anslutningsprofilen så att nästa jämförelse börjar med bevis.