Adăugați IPv6 privat într-un laborator OpenVPN, un punct de control pe rând

Aveți deja un client care se conectează prin IPv4 și ajunge la o încărcare de lucru IPv4 privată în spatele serverului. Scopul este să ajungeți la o încărcare de lucru IPv6 privată prin același tunel fără să atingeți transportul exterior. Această ordine contează: calea exterioară rămâne IPv4 și se schimbă doar planul de adrese interior, ruta clientului și calea de întoarcere de la server la LAN. Cinci puncte de control, fiecare cu ceva concret de verificat înainte de a merge mai departe.

Primul punct de control: conexiunea care funcționează deja

Conectați clientul și confirmați calea IPv4 înainte de a adăuga ceva. Un tunel funcțional vă dă o linie de bază care separă o eroare IPv6 nouă de o problemă veche de conectivitate. Vă spune și ce instanță de server editați de fapt.

Notați grupul, topologia și rutele împinse pe care vă bazați deja. Munca IPv6 extinde acea configurație; nu o înlocuiește.

Al doilea punct de control: alegeți prefixele interioare

Alegeți un ULA /48 pentru site și decupați două /64 din el: unul pentru clienții tunelului, unul pentru segmentul LAN care găzduiește încărcarea IPv6. Generați ID-ul global de 40 de biți în loc să copiați un prefix exemplu, și verificați ambele subrețele față de fiecare rețea pe care site-ul o rutează deja:

Outer transport: IPv4 OpenVPN UDP
IPv4 pool:       10.90.0.0/24
IPv6 VPN pool:   fd73:93bc:b6e9:77::/64
IPv6 LAN:        fd73:93bc:b6e9:60::/64
Server LAN IPv6: fd73:93bc:b6e9:60::1

Două /64 independente împiedică decuparea grupului de clienți din segmentul LAN, ceea ce contează mai târziu când scrieți ruta de întoarcere. Valorile de mai sus sunt un exemplu rezolvat, nu un prefix de reutilizat.

Al treilea punct de control: adăugați ajutorul și împingerea rutei

Citiți configurația actuală a serverului înainte de a adăuga ceva. O a doua copie a unei directive existente nu fuzionează cu prima, iar eroarea rezultată numește directiva, nu IPv6. Cu ajutorul IPv4 existent, două linii îl extind. Fiecare răspunde la o întrebare diferită:

server-ipv6 fd73:93bc:b6e9:77::/64
push "route-ipv6 fd73:93bc:b6e9:60::/64"

Prima este un ajutor comod care configurează interfața și grupul de clienți. A doua numește destinația LAN la care clientul trebuie să ajungă. A da unui client o adresă IPv6 nu îi spune ce rețele există în spatele serverului, așa că sunt necesare ambele linii.

Ajutorul nu coexistă cu un grup IPv6 static sau cu nopool. Dacă implementarea alocă deliberat adrese static, păstrați acea politică și proiectați explicit echivalentul IPv6 în loc să ștergeți politica pentru a se potrivi unui exemplu.

Al patrulea punct de control: redirecționarea și ruta de răspuns

Activați redirecționarea IPv6 pe server prin proprietarul de configurație al sistemului, nu printr-o scriere de runtime unică pe care o veți uita. Forma de runtime este utilă pentru un test rapid. Configurația persistentă aparține unui fișier drop-in pe care proprietarul de rețea al distribuției îl citește:

sysctl -w net.ipv6.conf.all.forwarding=1

Redirecționarea schimbă comportamentul IPv6 al gazdei dincolo de rutarea pachetelor. O gazdă care accepta anunțuri de router ca client încetează să o facă la fel de îndată ce redirecționează. De aceea o mașină al cărei uplink IPv6 depinde de RA are nevoie de un plan explicit pentru acel uplink.

Apoi dați LAN-ului o rută înapoi la grupul tunelului. Gateway-ul IPv6 al încărcării este routerul LAN, nu serverul VPN, așa că ruta aparține acelui router și indică adresa LAN a serverului:

ip -6 route add fd73:93bc:b6e9:77::/64 via fd73:93bc:b6e9:60::1

Păstrați tipurile ICMPv6 de care are nevoie legătura, inclusiv feedback-ul MTU al căii. O regulă de firewall IPv4 nu implică o regulă IPv6, iar o blocare totală a IPv6 strică descoperirea vecinilor în feluri care par o defecțiune de rutare.

Al cincilea punct de control: citiți clientul, apoi testați

Reconectați clientul și citiți adresele pe care le-a primit efectiv în loc să le deduceți din adresa ajutorului serverului. Lista interfețelor arată ambele familii pe același dispozitiv:

ip -6 addr show tun0
ip -6 route get fd73:93bc:b6e9:60::20

O rută care alege tunelul dovedește că clientul știe unde să trimită pachetul. Nu dovedește că serverul îl redirecționează, că routerul LAN are ruta de întoarcere sau că aplicației îi este permis să răspundă.

Testați aplicația în sine pe fiecare familie pe rând, apoi repetați după o reconectare și după o repornire a gazdei. O rută sau un sysctl care supraviețuiește doar până la repornire este un test, nu un proiect.

Publicați o înregistrare AAAA doar când calea IPv6 răspunde cap la cap. DNS-ul interogat prin IPv4 poate returna în continuare o adresă IPv6, așa că un nume rezolvabil nu este dovada că ceva ascultă. Ghidul RFC 4193 pentru ULA acoperă generarea ID-ului global care face aceste prefixe ale dumneavoastră, nu o copie.