Împărțirea /64-ului dumneavoastră nu rutează IPv6 către clienții VPN

Clientul afișează o adresă IPv6 globală, handshake-ul s-a încheiat și nimic nu se întoarce din internet. Setarea pool-ului pare corectă pentru că este corectă; adresa este validă și tunelul o transportă. Ceea ce eșuează este livrarea, iar livrarea depinde de o decizie luată deasupra serverului VPN pe care nicio configurație de pe partea clientului nu o poate influența.

Mitul: o parte din /64-ul dumneavoastră este deja accesibilă

Povestea este atrăgătoare: serverul are un /64 public, tăiați-l în două, dați cealaltă jumătate pool-ului VPN, iar acei clienți sunt acum pe internet. Împărțirea prefixului alocă într-adevăr adrese fără coliziuni. Dar nu schimbă modul în care rețeaua upstream decide unde trebuie să ajungă un pachet pentru una dintre acele adrese.

IPv6 nu are un strat de traducere implicit pe care să se sprijine, deci calea de întoarcere trebuie să existe ca rutare sau ca livrare la nivel de legătură. Un pachet adresat adresei de tunel a unui client ajunge la routerul upstream, iar acel router ia o decizie de redirecționare din propriul tabel. Dacă tabelul indică legătura fizică, pachetul merge acolo, indiferent ce crede serverul dumneavoastră VPN.

Aceasta este întreaga defecțiune: direcția înainte funcționează pentru că serverul dumneavoastră o trimite, iar direcția de întoarcere moare la un singur hop distanță pentru că upstream-ul nu a aflat niciodată că clientul există.

Ce necesită cu adevărat livrarea pe legătură

Când upstream-ul consideră că întregul /64 se află pe legătura fizică, rezolvă fiecare adresă de destinație prin descoperirea vecinilor. Trimite o cerere pe acea legătură și așteaptă ca proprietarul adresei să răspundă. Un client VPN aflat în spatele unui tunel nu este pe acea legătură și nu poate răspunde, așa că cererea rămâne fără răspuns și pachetul este eliminat.

Decuparea unui /65 nu schimbă această așteptare. Upstream-ul tratează în continuare intervalul ca fiind pe legătură, pentru că singurul lucru care i-ar schimba părerea este o rută sau un proxy care răspunde în numele clientului. Niciunul nu apare pentru că ați editat o configurație VPN. Exact acest gol explică de ce un pool poate funcționa perfect între propriii clienți și totuși poate fi inaccesibil din orice alt loc.

Descoperirea vecinilor prin proxy este mecanismul care poate conecta cele două lumi. Gateway-ul răspunde cererilor pentru adresele de client specifice pe care le deține și redirecționează traficul în tunel. Funcționează și trebuie limitat exact la acele adrese, cu un ciclu de viață care urmează pool-ul, pentru că răspunsul pentru o adresă pe care nu o mai deservești transformă traficul altcuiva într-o gaură neagră. Unele upstream-uri nu vor accepta răspunsuri proxy pe care nu le-au așteptat, așa că acest design are nevoie și de acordul furnizorului.

Ce necesită livrarea rutată

Designul mai curat este o alocare pe care upstream-ul o rutează într-adevăr către gateway-ul dumneavoastră. Poate fi un prefix delegat sau o rută statică pentru un bloc mai mic, iar cerința este aceeași în ambele cazuri: tabelul upstream-ului trebuie să indice serverul dumneavoastră pentru intervalul de clienți. Apoi traficul de întoarcere ajunge la gateway, iar gateway-ul îl redirecționează în tunel.

Livrarea rutată elimină complet întrebarea descoperirii vecinilor, motiv pentru care merită cerută furnizorului înainte de a construi ceva isteț. Cereți ruta în scris și confirmați că următorul hop este adresa pe care upstream-ul o poate atinge cu adevărat.

Ambele designe au în continuare nevoie de redirecționarea IPv6 activată pe gateway și de reguli de firewall care permit fluxul redirecționat în ambele direcții. Livrarea este o condiție prealabilă, nu un substitut, pentru restul căii. O rută funcțională cu redirecționarea dezactivată produce exact aceeași tăcere ca o rută lipsă, așa că verificați ambele înainte de a reproiecta ceva.

Două rute independente de stabilit corect

Prefixul pool-ului și ruta implicită proprie a clientului sunt setări separate, iar confuzia dintre ele produce conectivitate parțială care arată ca un tunel stricat. Pool-ul spune serverului ce adrese să distribuie. Rutele clientului decid către ce destinații trimite clientul trafic în tunel.

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

Prefixul de mai sus este spațiu de documentare, iar redirecționarea se aplică doar IPv6, ceea ce este exact ce dorește adesea un deployment cu două stive în timp ce livrarea IPv6 este încă reparată. O redirecționare IPv4 nu stabilește acoperire IPv6, iar niciuna dintre setări nu o implică pe cealaltă.

Mențineți traficul de control de care depinde IPv6 funcțional sub orice politică aplicați. Mesajele Packet Too Big sunt victima clasică a unui firewall care permite doar TCP și UDP, iar eliminarea lor produce conexiuni care se stabilesc și apoi se blochează la transferuri mai mari.

Anunțurile routerului sunt a treia piesă mobilă. Dacă gateway-ul începe să anunțe pe legătura superioară, poate schimba ceea ce cred clienții și vecinii despre prefixele de pe legătură, ceea ce poate anula în tăcere designul pe care tocmai l-ați documentat.

Înregistrați designul astfel încât o reconstrucție să îl reproducă

Notați trei obiecte separat: alocarea clientului, ruta de destinație a clientului și metoda de livrare a upstream-ului pentru alocare. Un cititor care le are pe toate trei poate reconstrui implementarea; un cititor care are doar setarea pool-ului va reproduce eroarea originală.

Apoi testați explicit direcția de întoarcere, cu un pachet care trebuie să revină din exterior. Manualul openvpn(8) acoperă opțiunile server-ipv6 și redirect, iar confirmarea de rutare de la furnizorul dumneavoastră acoperă jumătatea pe care manualul nu o poate acoperi.