IPv6-prefixdelegering över en plats-till-plats-VPN: checklista

Att få upp tunneln är den lätta halvan. Jag har sett en plats-till-plats-förbindelse stå etablerad i dagar medan varje värd på det avlägsna LAN:et bara fick tystnad tillbaka, eftersom det delegerade prefixet bakom den gatewayen var konfigurerat på ett gränssnitt men aldrig routat in i tunneln. Tunneladresserna svarade på ping hela tiden, och just därför tittade ingen på prefixet. Här är ordningen jag kontrollerar när ett delegerat IPv6-prefix måste korsa en plats-VPN: prefixkartan, trafikväljarna, vidarebefordran och brandväggen, och sedan returvägen.

Skriv prefixkartan innan du rör tunneln

Prefixdelegering ger ett block till den router som bad om det. Den installerar ingen rutt på motparten, utökar inte blocket on-link och berättar inte för den avlägsna gatewayen vad som ligger bakom den begärande routern. Dessa tre saker konfigurerar du själv, och de hör hemma i en adressplan innan någon konfigurationsfil ändras.

För varje plats, anteckna det delegerade prefixet, den /64 som faktiskt används på LAN:et, tunneladresserna och ägaren till varje rutt. Leverantören delegerar 2001:db8:a1::/56 till plats A, som betjänar 2001:db8:a1:10::/64 på sitt LAN; plats B behåller 2001:db8:b2::/64. Om plats A bara betjänar den enda /64:an bör båda ändarna ange 2001:db8:a1:10::/64 i stället för hela /56:an.

Två fel dyker nästan alltid upp. Det ena är att behandla det avlägsna prefixet som on-link, broa det eller sätta det på tunnelgränssnittet så att gatewayen svarar på grannförfrågningar för värdar den inte kan nå. Det andra är att annonsera hela /56:an när bara en /64 är konfigurerad: routingtabellen hävdar att blocket är nåbart och de flesta adresserna faller i svart hål.

Matcha båda ändarnas trafikväljare mot rutterna

IKEv2 och WireGuard avvisar båda trafik som inte stämmer, tillräckligt tyst för att tunneln fortfarande ska se frisk ut.

I strongSwan är väljarna explicita. På plats A:

conn a-to-b
    left=2001:db8:ff::1
    leftsubnet=2001:db8:a1:10::/64
    right=2001:db8:ff::2
    rightsubnet=2001:db8:b2::/64
    auto=start

Plats B:s conn speglar de två subnäten. När de inte stämmer avvisar svararen CHILD_SA med TS_UNACCEPTABLE, så child SA kommer aldrig upp trots att IKE_SA gjorde det. På båda sidor måste det konfigurerade subnätet vara lika med det som den lokala kärnan routar mot tunneln.

WireGuard bär samma information i AllowedIPs, med en tvist: AllowedIPs är ett källfilter vid mottagning och en rutt vid sändning. Om plats B:s peer-post för plats A utelämnar 2001:db8:a1:10::/64 kommer paket från plats A in på ett giltigt handshake och släpps som otillåtna. Det ger det välbekanta mönstret med ett handshake som ständigt förnyas medan inget svar någonsin går ut. Jämför båda ändarna med wg show wg0 allowed-ips. Kontrollera listan igen varje gång delegeringen ändras; en inaktuell /64 håller sessionen vid liv och det nya prefixet onåbart.

Uteslut vidarebefordran, brandvägg och MTU först

Innan du läser ännu en logg rad, bekräfta att gatewayerna vidarebefordrar överhuvudtaget. sysctl net.ipv6.conf.all.forwarding måste returnera 1 på båda, tillämpat även på tunnel- och LAN-gränssnitten. En fälla följer med: när vidarebefordran är på slutar ett gränssnitt med accept_ra=1 att acceptera routerannonser från leverantören, så maskinen kan förlora sin uppströms standardrutt trots att den routar perfekt inne i tunneln. Sätt accept_ra=2 där en leverantörs-RA fortfarande behövs.

Brandväggsreglerna måste sedan tillåta prefixet i båda riktningarna, och ICMPv6 måste överleva: grannupptäckt, packet-too-big och destination-unreachable är inte valfria. Släpper du dem går path-MTU-upptäckten sönder och du får anslutningar som öppnas och sedan stannar på det första stora svaret. Ett minimalt regelpar ser ut så här:

nft add rule inet filter forward ip6 saddr 2001:db8:a1:10::/64 ip6 daddr 2001:db8:b2::/64 accept
nft add rule inet filter forward ip6 saddr 2001:db8:b2::/64 ip6 daddr 2001:db8:a1:10::/64 accept
nft add rule inet filter forward icmpv6 type { packet-too-big, nd-neighbor-solicit, nd-neighbor-advert } accept

MTU:n ligger bakom detta. En tunnel krymper den användbara MTU:n under 1500, och IPv6 kräver att varje länk bär minst 1280. Små ping går igenom, en SSH-session fryser vid en stor skur, och /proc/net/snmp6 visar packet-too-big-meddelanden som aldrig kommer tillbaka. Sätt tunnelns MTU explicit, eller begränsa TCP MSS i mangle-tabellen, och låt ICMPv6 som meddelar mindre MTU komma tillbaka.

Testa returvägen, inte tunneladressen

Felet som kostar mest tid är enkelriktad routning. Varje gateway routar det avlägsna prefixet in i tunneln, men värdar svarar via sin egen standardgateway eftersom det är där deras /64 bor. Att få ett paket till målet är halva vägen.

Två kommandon löser det mesta. På plats A visar ip -6 route get 2001:db8:b2::53 from 2001:db8:a1:10::5 vilket gränssnitt ett svar från den källan skulle använda; kör spegelkontrollen på plats B. Generera sedan trafik från en värd i stället för gatewayen, och jämför räknarna i båda ändarna.

Om grannförfrågan för det avlägsna prefixet dyker upp på tunneln, är det prefixet on-link någonstans där det inte borde vara; åtgärda det innan du justerar rutter. Proxy NDP täcker fall där broing verkligen behövs, inte en ersättning för en rutt.

Planera för att prefixet ändras under dig

Prefixdelegering är ett leaseavtal mellan den delegerande och den begärande routern, och en förnyelse kan ge ett annat block: en annan /56 efter en leverantörsmigrering, eller en kortare lease än tunneln har varit uppe. Varje plats som namnger det gamla prefixet blir inaktuell samtidigt: rutter, väljare, AllowedIPs, brandväggsregler, DNS-poster och all övervakning som hårdkodar litterala adresser. Meddelandeflödet finns i RFC 8415.

Där prefixet förväntas flytta sig, håll en intern adressplan som inte beror på det och översätt vid gränsen. NPTv6 är det tillståndslösa alternativet och håller den interna policyn läsbar, men det är prefixöversättning, inte ett magiskt lager: /64-gränser måste stämma, kontrollsummor justeras, och applikationer som bäddar in litterala adresser går fortfarande sönder. Om du behåller leverantörens adresser hela vägen, anteckna leasebeteendet och en ändringsprocedur i adressplanen.

Avsluta med ett test som står emot tiden: en tillåten värd på varje LAN når en tjänst på det andra LAN:et, svaret kommer tillbaka genom tunneln, och samma par fungerar fortfarande efter en omstart av tunneln och en förnyelse av delegeringen. Om den sista delen misslyckas beror designen på tillstånd som inte överlever veckan.