Delegarea prefixului IPv6 printr-o VPN sit-la-sit: listă de verificare

Ridicarea tunelului este jumătatea ușoară. Am văzut o legătură sit-la-sit rămânând stabilită zile întregi în timp ce fiecare gazdă din LAN-ul îndepărtat primea doar tăcere, pentru că prefixul delegat din spatele acelui gateway era configurat pe o interfață, dar nu fusese niciodată rutat în tunel. Adresele tunelului răspundeau la ping tot timpul, și exact de aceea nimeni nu se uita la prefix. Iată ordinea pe care o verific atunci când un prefix IPv6 delegat trebuie să traverseze o VPN de sit: harta prefixelor, selectoarele de trafic, forwardingul și firewallul, apoi calea de retur.

Scrie harta prefixelor înainte să atingi tunelul

Delegarea prefixului dă un bloc routerului care l-a cerut. Nu instalează o rută la peer, nu extinde acel bloc on-link și nu îi spune gatewayului îndepărtat ce se află în spatele routerului solicitant. Aceste trei lucruri trebuie configurate de tine, și își au locul într-un plan de adresare înainte ca vreun fișier de configurare să se schimbe.

Pentru fiecare sit, notează prefixul delegat, /64 folosit efectiv în LAN, adresele tunelului și proprietarul fiecărei rute. Furnizorul deleagă 2001:db8:a1::/56 sitului A, care servește 2001:db8:a1:10::/64 în LAN-ul său; situl B păstrează 2001:db8:b2::/64. Dacă situl A servește doar acel /64, ambele capete ar trebui să numească 2001:db8:a1:10::/64, nu întregul /56.

Aproape mereu apar două greșeli. Una este să tratezi prefixul îndepărtat ca on-link, să îl punti sau să îl pui pe interfața tunelului, astfel încât gatewayul să răspundă la solicitările de vecinătate pentru gazde pe care nu le poate atinge. Cealaltă este să anunți întregul /56 când este configurat doar un /64: tabela de rute susține că blocul este accesibil, iar majoritatea adreselor cad într-o gaură neagră.

Aliniază selectoarele de trafic ale ambelor capete la rute

IKEv2 și WireGuard refuză amândouă traficul nepotrivit, suficient de silențios încât tunelul să pară în continuare sănătos.

În strongSwan selectoarele sunt explicite. La situl 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

conn-ul sitului B oglindește cele două subrețele. Când nu sunt de acord, responderul respinge CHILD_SA cu TS_UNACCEPTABLE, așa că child SA nu urcă niciodată, deși IKE_SA a urcat. Pe ambele părți subrețeaua configurată trebuie să fie egală cu ceea ce kernelul local rutează spre tunel.

WireGuard transportă aceleași informații în AllowedIPs, cu o răsucire: AllowedIPs este filtru de sursă la recepție și rută la trimitere. Dacă intrarea peer a sitului B pentru situl A omite 2001:db8:a1:10::/64, pachetele de la situl A ajung pe un handshake valid și sunt aruncate ca nepermise. Asta produce tiparul familiar al unui handshake care se reînnoiește continuu în timp ce niciun răspuns nu pleacă. Compară ambele capete cu wg show wg0 allowed-ips. Reverifică lista ori de câte ori se schimbă delegarea; un /64 învechit ține sesiunea vie și noul prefix inaccesibil.

Exclude mai întâi forwardingul, firewallul și MTU-ul

Înainte să citești încă o linie de log, confirmă că gatewayurile fac forwarding. sysctl net.ipv6.conf.all.forwarding trebuie să returneze 1 pe ambele, aplicat și interfețelor tunelului și LAN-ului. Vine la pachet o capcană: odată activat forwardingul, o interfață cu accept_ra=1 nu mai acceptă anunțurile de router de la furnizor, așa că mașina poate pierde ruta implicită din amonte deși rutează perfect în interiorul tunelului. Setează accept_ra=2 acolo unde RA-ul furnizorului este încă necesar.

Regulile de firewall trebuie apoi să permită prefixul în ambele direcții, iar ICMPv6 trebuie să supraviețuiască: descoperirea vecinilor, packet-too-big și destination-unreachable nu sunt opționale. Dacă le arunci, descoperirea MTU a căii se rupe și obții conexiuni care se deschid și apoi se blochează la primul răspuns mare. O pereche minimă de reguli arată așa:

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-ul stă în spatele acestui lucru. Un tunel micșorează MTU-ul utilizabil sub 1500, iar IPv6 cere ca fiecare legătură să transporte cel puțin 1280. Pingurile mici trec, o sesiune SSH îngheață la un val mare, iar /proc/net/snmp6 arată mesaje packet-too-big care nu se întorc niciodată. Setează explicit MTU-ul tunelului sau limitează MSS-ul TCP în tabela mangle și lasă ICMPv6 care anunță MTU-ul mai mic să revină.

Testează calea de retur, nu adresa tunelului

Defecțiunea care consumă cel mai mult timp este rutarea unidirecțională. Fiecare gateway rutează prefixul îndepărtat în tunel, dar gazdele răspund prin propriul gateway implicit pentru că acolo locuiește /64-ul lor. A duce un pachet la destinație este jumătate de drum.

Două comenzi rezolvă cea mai mare parte. La situl A, ip -6 route get 2001:db8:b2::53 from 2001:db8:a1:10::5 arată ce interfață ar folosi un răspuns din acea sursă; rulează verificarea în oglindă la situl B. Apoi generează trafic dintr-o gazdă, nu din gateway, și compară contoarele la ambele capete.

Dacă solicitarea de vecinătate pentru prefixul îndepărtat apare pe tunel, acel prefix este on-link undeva unde nu ar trebui; repară asta înainte de a ajusta rutele. Proxy NDP acoperă cazurile în care puntea este cu adevărat necesară, nu înlocuiește o rută.

Planifică schimbarea prefixului sub tine

Delegarea prefixului este un contract de închiriere între routerul care delegă și cel care solicită, iar reînnoirea poate returna alt bloc: alt /56 după o migrare a furnizorului sau o închiriere mai scurtă decât timpul cât tunelul a fost ridicat. Fiecare loc care numește prefixul vechi devine învechit deodată: rute, selectoare, AllowedIPs, reguli de firewall, înregistrări DNS și orice monitorizare care codifică adrese literale. Fluxul mesajelor este în RFC 8415.

Unde se așteaptă ca prefixul să se miște, păstrează un plan de adresare intern care nu depinde de el și tradu la graniță. NPTv6 este opțiunea fără stare și păstrează politica internă lizibilă, dar este traducere de prefix, nu un strat magic: granițele /64 trebuie să se alinieze, sumele de control sunt ajustate, iar aplicațiile care încorporează adrese literale tot se strică. Dacă păstrezi adresele furnizorului cap la cap, notează comportamentul închirierii și o procedură de schimbare în planul de adresare.

Încheie cu un test care rezistă în timp: o gazdă permisă din fiecare LAN ajunge la un serviciu din cealaltă LAN, răspunsul se întoarce prin tunel, iar aceeași pereche funcționează și după o repornire a tunelului și o reînnoire a delegării. Dacă ultima parte eșuează, designul depinde de o stare care nu va supraviețui săptămânii.