Traficul IPv6 ar trebui să treacă prin VPN sau direct?

Luna trecută două persoane mi-au cerut rezultate opuse: una voia ca VPN-ul să acopere IPv6, cealaltă voia ca imprimanta biroului să continue să funcționeze. O singură rută ::/0 nu poate oferi ambele de una singură. Dacă acea rută aparține în interiorul tunelului depinde de trei condiții, iar prima o exclude pentru majoritatea ieșirilor comerciale. Dacă ieșirea nu transportă IPv6, rutarea rutei implicite acolo îți ascunde traficul într-un tunel care nu are unde să-l trimită.

Trei condiții decid răspunsul

Ruta implicită este o singură linie, ::/0, și se potrivește oricărei destinații IPv6 fără o rută mai specifică (RFC 4291). Instalarea ei este ușoară. Decizia dacă ar trebui se reduce la trei condiții.

Condiția unu: ieșirea la care te conectezi are IPv6 funcțional și este dispusă să îl transmită mai departe. Condiția doi: clientul tău poate păstra o cale către punctul final al tunelului, care de obicei se află în intervalul pe care urmează să îl rutezi. Condiția trei: poți numi destinațiile IPv6 locale care trebuie să rămână în afara tunelului.

Fiecare condiție eșuează în felul ei, de aceea ghicitul costă o seară întreagă. O condiție unu eșuată îți dă liniște și un tabel de rute care pare corect. O condiție doi eșuată ucide handshake-ul câteva secunde după ce începe. O condiție trei eșuată lasă un tunel funcțional și un coleg nemulțumit la imprimantă.

Ieșirea transportă într-adevăr IPv6?

O interfață de tunel cu o adresă IPv6 nu dovedește nimic despre cealaltă parte. Multe profiluri comerciale sunt doar IPv4 în interior: serverul îți dă o adresă v4 și aruncă restul. Instalează deasupra o rută implicită din AllowedIPs și kernelul va trimite bucuros IPv6 într-o interfață pe care partenerul ei nu o vede niciodată.

Testează din client cât timp tunelul este activ. ping -6 -c 3 2001:4860:4860::8888 și ip -6 route get 2001:4860:4860::8888 răspund la întrebări diferite: dacă se întoarce un răspuns și ce dispozitiv a ales kernelul. Când al doilea numește tunelul tău, iar primul nu returnează nimic, problema este ieșirea, nu ruta.

Dacă administrezi singur ieșirea, testul clientului poate trece și calea tot poate ajunge într-o fundătură. Confirmă net.ipv6.conf.all.forwarding=1 pe gateway și că firewall-ul acestuia acceptă pachete transmise din tunel. Un pachet rutat corect într-o ieșire care refuză să retransmită arată exact ca o eroare de rutare din partea clientului.

Poate clientul să își păstreze calea către punctul final?

Acesta este cazul care m-a prins pe un laptop cu un punct final WireGuard doar IPv6. Adresa punctului final este o adresă globală obișnuită, așa că se încadrează în ::/0. Rutează întregul prefix în interfață și pachetele de handshake se vor urmări singure în tunelul pe care încă încearcă să îl construiască. Tunelul nu urcă niciodată, iar nimic din ieșirea clientului nu spune de ce.

wg-quick se ocupă de asta pe Linux. Derivă rute din AllowedIPs, le instalează în propriul tabel și adaugă o regulă de politică astfel încât traficul către punctul final să fie rezolvat mai întâi prin tabelul principal: regula suppress_prefixlength 0 pe care o găsești în ip -6 rule. De aceea wg-quick up reușește acolo unde o ip -6 route add default dev wg0 scrisă manual te taie.

Verifică ambele stări cu ip -6 route get <endpoint-v6>, înainte și după ridicarea tunelului. Dacă răspunsul se schimbă către dispozitivul tău de tunel, ai eliminat calea de care are nevoie tunelul. Când scrii rutele singur, adaugă o rută de gazdă către punctul final prin gateway-ul original, sau conectează-te la punctul final prin IPv4 și lasă IPv6 pentru payload.

Ce trebuie să rămână în afara tunelului?

Rutele mai specifice înving ruta implicită, așa că un prefix on-link sau un interval ULA cu rută proprie continuă să funcționeze fără efort suplimentar. Acesta este motivul tăcut pentru care atât de multe configurații IPv4 cu tunel complet supraviețuiesc: prefixele LAN sunt mai specifice decât cea implicită și nu intră niciodată în tunel.

Se rupe când un dispozitiv local este accesibil printr-o adresă globală, ceea ce este normal pentru o imprimantă căreia același router i-a dat un prefix public, un NAS sau un televizor. Acele adrese corespund cu ::/0 și cu nimic altceva, așa că se mută în tunel împreună cu tot restul și dispar.

Decide pe destinație, nu pe protocol. Dacă doi sau trei gazde locale contează, dă prefixelor lor o rută spre exterior prin interfața fizică, sau scoate-le din setul negociat. Dacă lista continuă să crească, răspunsul onest este split tunneling pentru IPv6 cu o listă scrisă de excepții, nu o rută implicită pe care o tot petici.

Dacă răspunsul este nu, blochează-l

Să lași IPv6 fără rută nu este același lucru cu a-l lăsa în pace. O gazdă cu o rută implicită IPv6 funcțională o folosește în continuare cât timp tunelul transportă IPv4, așa că traficul iese pe lângă VPN și fiecare serviciu care preferă IPv6 vede adresa ta reală. Aceasta este o scurgere, nu un tunel divizat.

Alege una și notează pe care ai ales-o. Rutează ruta implicită și acceptă compromisurile de mai sus, sau dezactivează IPv6 pe durata tunelului. Omiterea prefixului din AllowedIPs nu este suficientă singură, pentru că sistemul de operare își păstrează propria rută implicită. Pe Linux versiunea brutală este sysctl -w net.ipv6.conf.all.disable_ipv6=1; versiunea mai fină aruncă IPv6 în afara tunelului cu o regulă de firewall. Clienții de telefon au un comutator explicit de blocare a IPv6 care face aceeași treabă.

Verifică-l ca pe o scurgere

Ridică tunelul și citește starea în loc să te bazezi pe comutator. ip -6 route show default ar trebui să arate o singură rută implicită, iar ip -6 route get pentru o destinație din afara LAN-ului tău ar trebui să numească dispozitivul de tunel. Repetă ambele după o deconectare: o rută implicită care supraviețuiește tunelului este eroarea pe care o căutai.

Apoi testează cealaltă direcție. De pe o gazdă din rețeaua locală, ajunge la client pe adresa lui IPv6 locală. Dacă asta nu mai funcționează, condiția trei nu a fost niciodată îndeplinită, orice ar fi susținut tabelul de rute atunci.

Scrie rezultatul acolo unde îl va găsi următoarea persoană: ce prefixe rămân locale, de ce și ce face clientul după o deconectare. Două linii într-un runbook îl scutesc pe următorul inginer de a redescoperi bucla punctului final la miezul nopții.