Att dela upp ditt /64 dirigerar inte IPv6 till VPN-klienter

Klienten visar en global IPv6-adress, handskakningen är klar och ingenting kommer tillbaka från internet. Poolinställningen ser korrekt ut eftersom den är korrekt; adressen är giltig och tunneln bär den. Det som misslyckas är leveransen, och leveransen beror på ett beslut som fattas ovanför VPN-servern och som ingen konfiguration på klientsidan kan påverka.

Myten: en del av ditt /64 är redan nåbar

Berättelsen är lockande: servern har ett offentligt /64, dela det på mitten, ge den andra halvan till VPN-poolen, och de klienterna är nu på internet. Att dela prefixet tilldelar verkligen adresser utan kollisioner. Det ändrar dock inte hur upstream-nätverket avgör vart ett paket för en av dessa adresser ska gå.

IPv6 har inget standardöversättningslager att falla tillbaka på, så returvägen måste finnas som routning eller som leverans på länknivå. Ett paket adresserat till en klients tunneladress anländer till upstream-routern, och den routern fattar ett vidarebefordransbeslut utifrån sin egen tabell. Om tabellen pekar på den fysiska länken går paketet dit, oavsett vad din VPN-server tror.

Det är hela felet: riktningen framåt fungerar eftersom din server skickar den, och returriktningen dör ett hopp bort eftersom upstream aldrig fick veta att klienten finns.

Vad leverans på länken egentligen kräver

När upstream betraktar hela /64:an som belägen på den fysiska länken löser den upp varje destinationsadress med grannupptäckt. Den skickar en förfrågan på länken och förväntar sig att adressens ägare svarar. En VPN-klient bakom en tunnel finns inte på den länken och kan inte svara, så förfrågan förblir obesvarad och paketet kastas.

Att skära ut ett /65 ändrar inte den förväntan. Upstream behandlar fortfarande intervallet som på länken, eftersom det enda som skulle få den att ändra sig är en rutt eller en proxy som svarar å klientens vägnar. Ingen av dem dyker upp eftersom du redigerade en VPN-konfiguration. Just detta gap förklarar varför en pool kan fungera perfekt mellan sina egna klienter och ändå vara onåbar från alla andra håll.

Proxy-grannupptäckt är mekanismen som kan överbrygga de två världarna. Gatewayen svarar på förfrågningar för de specifika klientadresser den äger och vidarebefordrar trafiken in i tunneln. Det fungerar, och det måste begränsas exakt till dessa adresser med en livscykel som följer poolen, eftersom att svara för en adress du inte längre betjänar gör någon annans trafik till ett svart hål. Vissa upstreams accepterar inte proxy-svar de inte förväntade sig, så den här designen behöver även leverantörens godkännande.

Vad routad leverans kräver

Den renare designen är en tilldelning som upstream faktiskt routar till din gateway. Det kan vara ett delegerat prefix eller en statisk rutt för ett mindre block, och kravet är detsamma i båda fallen: upstreams tabell måste peka på din server för klientintervallet. Då anländer returtrafiken till gatewayen och gatewayen vidarebefordrar den in i tunneln.

Routad leverans tar bort frågan om grannupptäckt helt, och därför är det värt att be leverantören om det innan du bygger något smart. Be om rutten skriftligen och bekräfta att nästa hopp är den adress som upstream faktiskt kan nå.

Båda designerna behöver fortfarande IPv6-vidarebefordran aktiverad på gatewayen och brandväggsregler som tillåter det vidarebefordrade flödet i båda riktningarna. Leverans är en förutsättning, inte en ersättning, för resten av vägen. En fungerande rutt med vidarebefordran avstängd ger exakt samma tystnad som en saknad rutt, så kontrollera båda innan du gör om något.

Två oberoende rutter att få rätt på

Poolens prefix och klientens egen standardrutt är separata inställningar, och att blanda ihop dem ger delvis anslutning som ser ut som en trasig tunnel. Poolen talar om för servern vilka adresser som ska delas ut. Klientens rutter avgör vilka destinationer klienten över huvud taget skickar in i tunneln.

server-ipv6 2001:db8:42:100::/64
push "redirect-gateway ipv6 !ipv4"

Prefixet ovan är dokumentationsutrymme, och omdirigeringen gäller endast IPv6, vilket är precis vad en dual-stack-utrullning ofta vill medan IPv6-leveransen fortfarande repareras. En IPv4-omdirigering etablerar ingen IPv6-täckning, och ingen av inställningarna förutsätter den andra.

Håll den kontrolltrafik som IPv6 är beroende av igång under vilken policy du än tillämpar. Packet Too Big-meddelanden är det klassiska offret för en brandvägg som bara tillåter TCP och UDP, och att kasta dem ger anslutningar som upprättas och sedan stannar vid större överföringar.

Routerannonseringar är den tredje rörliga delen. Om gatewayen börjar annonsera på upplänken kan det ändra vad klienter och grannar tror om prefix på länken, vilket i tysthet kan upphäva den design du just dokumenterade.

Dokumentera designen så att en återuppbyggnad återskapar den

Skriv ned tre objekt var för sig: klientens tilldelning, klientens destinationsrutt och upstreams leveransmetod för tilldelningen. En läsare som har alla tre kan bygga om distributionen; en läsare som bara har poolinställningen kommer att återskapa det ursprungliga felet.

Testa sedan returriktningen uttryckligen med ett paket som måste komma tillbaka utifrån. Handboken för openvpn(8) täcker alternativen server-ipv6 och redirect, och din leverantörs routingbekräftelse täcker den halva handboken inte kan.