IPv6 genom en OpenVPN-tunnel: en genomgång av hemroutern

Den bärbara datorn har en IPv6-adress, tunneln är uppe över IPv4 och ändå misslyckas varje IPv6-test. Eller värre: testet lyckas och trafiken lämnade leverantörens väg utan att någonsin komma in i tunneln. Båda utfallen går tillbaka till ett enda saknat beslut: ingen gav routern ett prefix som den kunde routa mot klienterna. Att gå vägen från klienten och utåt hittar vilken bit som saknas.

Börja där klienten sitter

Titta på klienten innan du rör servern. ip -6 addr bör visa en tunneladress från poolen, och ip -6 route bör visa det pushade prefixet som pekar på tunnelenheten. När adressen finns men vägen inte, saknas pushen eller så ignorerade klienten den. När ingen av dem finns har servern inte tilldelat någonting alls.

Kontrollera sedan vad klienten tror om omvärlden. En standardväg över tunneln kräver all IPv6-trafik, medan en väg för 2000::/3 bara kräver global unicast. Båda kan vara riktiga, och de svarar på olika frågor om läckage.

En klient utan någon IPv6-standardväg misslyckas på varje offentligt test trots att tunneln själv är helt frisk. Det är en lucka i policyn, inte en trasig tunnel.

Kontrollera poolen som servern faktiskt kan routa

En server kan bara tilldela från ett prefix som den faktiskt kontrollerar. Om leverantören delegerar ett /56, reservera ett /64 för tunneln och låt resten vara till LAN. Där leverantören bara lämnar över ett enda /64 på WAN och inte routar något mer, låt LAN-prefixet vara och ge tunneln ett unikt lokalt område, medan du accepterar att klienterna inte får någon global utgång.

Poolen och pushen hör ihop. server-ipv6 2001:db8:80:10::/64 tilldelar adresser, och push "route-ipv6 2000::/3" berättar för klienterna vad de ska skicka in i tunneln. Att pusha 2000::/3 täcker global unicast och håller link-local- och multicast-områden utanför tunneln.

Skriv det valda prefixet i utrullningsprotokollet. Den som nästa gång ändrar leverantörens överlämning måste veta vilket /64 tunneln redan upptar.

Slå på vidarebefordran för den andra familjen

IPv4-vidarebefordran innebär inte IPv6-vidarebefordran. Sätt net.ipv6.conf.all.forwarding=1 och spegla allt som IPv4-FORWARD-policyn redan tillåter. På en router vars FORWARD-kedja droppar som standard ser en saknad regeluppsättning exakt ut som en död tunnel.

Handskakningen lyckas, klienten får en adress och ingenting kommer tillbaka. Lägg till regler för båda riktningarna och för WAN-benet, eftersom en tunnel som når LAN men inte internet misslyckas på det tredje testet. Titta på kedjans räknare efter ett misslyckat försök, eftersom en regel som aldrig matchade är ett annat problem än en som matchade och droppade.

ip6tables -A FORWARD -i br0 -o tun0 -j ACCEPT
ip6tables -A FORWARD -i tun0 -o br0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
ip6tables -A FORWARD -i tun0 -o wan0 -j ACCEPT

En bieffekt fångar dem som till slut skyller på tunneln. När vidarebefordran slås på hoppar kärnan över adresskonfiguration via Router Advertisement om du inte säger annat, och en standardväg som lärts så försvinner med den. Antingen fäster du en uttrycklig standardväg på WAN-gränssnittet, eller så sätter du accept_ra medvetet till 2 där. Efter varje ändring, bekräfta att routern fortfarande har en användbar IPv6-väg ut innan du testar klienterna igen.

Svara på granndetektering när uppströmmen inte routar

Utrustning uppströms behandlar ibland det delegerade /64 som tillhörande sin egen länk och vägrar routa något underprefix till VPN-lådan. När det händer måste något svara på granförfrågningar för varje klientadress individuellt.

OpenVPN exponerar den tilldelade adressen till en client-connect-krok, så poster kan följa den riktiga poolen i stället för en lista som hålls för hand. Kroken lägger till ip -6 neigh add proxy $ifconfig_pool_remote_ip6 dev eth0, och en matchande client-disconnect-krok tar bort den. Utan borttagningen blir proxy-tabellen inaktuell och en senare klient kan ärva en post för en adress som den aldrig fick. Bekräfta tillståndet med ip -6 neigh show proxy.

Betrakta proxy som en nödlösning. En statisk väg för tunnelns /64 riktad mot routern överlever klientbyten och behöver ingen privilegierad shell-krok alls.

Följ vägen utåt, hopp för hopp

Testa utåt i tre steg: först routerns tunneladress, sedan en LAN-värd och tredje ett offentligt mål via traceroute6. Poolen bevisas av det första, vidarebefordran och LAN-brandväggen av det andra, och returvägen via uppströmmen av det tredje. Varje fel smalnar av sökningen till en enda enhet i stället för att öppna hela designen igen.

Håll koll på tunnelns MTU, eftersom IPv6-routrarna på vägen inte fragmenterar åt dig. En för stor MTU visar sig som ett packet-too-big-fel och fastlåst TLS i stället för ett rent fel. Sätt den uttryckligen och testa med en last nära gränsen.