IPv6 printr-un server VPN IPv4 are în continuare nevoie de o ieșire IPv6

Tunelul urcă, clientul primește o adresă IPv6 din pool, și totuși fiecare destinație IPv6 expiră. În tunel nu e nimic stricat: IPv6 circulă foarte bine în transportul IPv4, și asta nu a fost niciodată partea grea. Adresa pe care ai distribuit-o este o promisiune pe care serverul nu o poate ține, pentru că ieșirea nu are niciun upstream IPv6 în care să o trimită. Reparația aparține ieșirii, nu profilului clientului.

Simptomul: o adresă și niciun drum

O verificare pe partea clientului arată o adresă IPv6 cu aspect global pe dispozitivul de tunel și o rută care indică spre ea, motiv pentru care acest lucru este citit greșit ca o eroare a clientului. Traficul intră în tunel, serverul îl decapsulează, iar apoi pachetul ajunge pe un host a cărui tabelă de rutare nu are nicio rută implicită IPv6 către un loc real. În funcție de stivă, primești inaccesibilitate imediată sau o aruncare silențioasă, iar în ambele cazuri clientul vede un timeout care arată identic cu un firewall.

Citește tabela de rutare a serverului însuși înainte de a atinge clientul, pentru că acolo locuiește jumătatea lipsă a drumului. Un server cu o singură rută implicită IPv4 ți-a dat deja răspunsul.

Urmărește pachetul după decapsulare

În interiorul tunelului pachetul este IPv6 obișnuit, iar sursa lui este adresa clientului. Serverul îndepărtează încapsularea de transport și apoi ține un pachet IPv6 nativ care trebuie transmis către următorul salt IPv6. O rută implicită IPv4 nu îl poate duce, iar traducerea lui în IPv4 este altă funcție pe care nimeni nu a implementat-o. Aceasta este întreaga defecțiune și nu are nimic de-a face cu faptul că ascultătorul VPN a răspuns sau nu prin IPv4.

Mecanica încapsulării IPv6 peste IPv4 este descrisă în RFC 4213, iar detaliul important de acolo este că punctele de capăt au în continuare nevoie de conectivitate IPv6 reală de cealaltă parte a tunelului. Înfășurarea unui antet nu creează un upstream.

Două straturi de tunel, două verificări independente

Verifică fiecare strat separat, pentru că un tunel exterior funcțional ascunde unul interior stricat. Verifică drumul exterior cu un ping IPv4 de la client la server și confirmă portul pe care îl folosești. Apoi verifică drumul interior pe server, unde ip -6 route trebuie să arate o rută implicită sau o rută specifică învățată de la un upstream real, și ip -6 addr trebuie să arate un prefix sursă pe care upstreamul îl acceptă. Orice mai puțin de asta este doar decor pe interfață.

O adresă unic-locală, sau un prefix cu aspect global către care nimic nu rutează înapoi, va apărea fericit pe o interfață și nu va merge nicăieri. Accesibilitatea publică este acordată de upstream, nu de forma adresei.

Același lucru este valabil la client: ip -6 route get 2001:4860:4860::8888 ar trebui să numească dispozitivul de tunel, iar dacă îl numește pe cel fizic, clientul nu folosește deloc VPN-ul pentru IPv6.

Prefix sursă, dimensiune și ICMPv6

Întreabă upstreamul ce prefixe sursă va accepta pentru redirecționare și folosește unul dintre ele pentru pool-ul de clienți. Un furnizor care îți dă un /64 pentru interfața serverului însuși nu îți rutează neapărat un al doilea /64 sau un bloc mai mare, iar diferența este o după-amiază de depanare pe care un tichet de suport o rezolvă cu o singură întrebare. Întreabă în scris și păstrează răspunsul lângă configurație.

Bugetează încapsularea suplimentară pe care stiva ta o folosește efectiv și menține ICMPv6 funcțional, inclusiv Packet Too Big. Un al doilea antet micșorează încărcătura utilă, așa că un drum care răspunde la ping-uri mici poate eșua totuși la un transfer de fișiere, iar un firewall care aruncă tot ICMPv6 transformă o problemă de dimensiune reparabilă într-o gaură neagră. Testează un transfer mare înainte de a anunța serviciul.

Ce este o problemă complet diferită

A ajunge la o aplicație doar IPv4 dintr-un client doar IPv6 este traducere, nu tunelare, și are nevoie de ceva ca o implementare deliberată de NAT64. Destinația nu va înțelege un antet de tunel suplimentar doar pentru că ai adăugat unul. Serviciile istorice de tranziție merită aceeași grijă: RFC 7526 a retras modelul de releu anycast 6to4, așa că un ghid scris în jurul lui descrie ceva care nu mai are un releu public întreținut.

Dacă serverul nu are niciun upstream IPv6 utilizabil, opțiunile sunt un upstream acceptat, o altă ieșire sau o decizie documentată că IPv6 rămâne în afara tunelului. Ceea ce nu este acceptabil este să le spui clienților că există un serviciu IPv6 în timp ce conexiunea lor obișnuită IPv6 ocolește VPN-ul în tăcere.