Traficul IPv6 care ocolește VPN-ul: găsește ruta care pierde

Două pagini de test nu sunt de acord: una raportează adresa furnizorului prin tunel, a doua raportează prefixul tău de acasă, iar concluzia evidentă este că VPN-ul pierde. Acea concluzie sare peste un pas, pentru că cele două rapoarte au exercitat două decizii de rutare diferite și doar una dintre ele trebuia să intre în tunel. Golul este de obicei real și este o problemă de acoperire, nu un tunel stricat. Trei întrebări îl lămuresc: ce flux a ieșit de fapt, ce rută a ales nucleul pentru el și ce comportament intenționa clientul.

Lucrează în această ordine. Dacă răspunzi în altă ordine, apare o discuție lungă despre dacă clientul este defect, când răspunsul real este că nu a fost instalată niciodată o rută IPv6.

Ce flux a ieșit de fapt și pe ce adaptor

Începe cu un test care numește familia folosită, apoi notează aplicația, rețeaua de acces, profilul în vigoare și dacă conexiunea oferă deloc IPv6. Aceste patru fapte fac două rulări comparabile, iar al patrulea este cel pe care oamenii îl uită: o rețea fără prefix v6 nu poate pierde v6, iar o rețea care adaugă unul mai târziu schimbă răspunsul.

Trimite o cerere pe familie în loc să încarci o pagină și să citești rezultatul. O singură pagină poate amesteca resurse v6 și v4, un proces din fundal se poate comporta diferit față de fila din fața ta, iar un răspuns din cache poate supraviețui schimbării de rețea pe care încerci să o testezi. Fixează destinația pe care o testezi și noteaz-o, ca o rulare repetată să măsoare același lucru.

Citirea rutei alese de nucleu

Tabelul de rutare răspunde la întrebarea la care browserul nu poate. Întreabă sistemul încotro ar merge o destinație anume și include atât regulile de politică, cât și ruta implicită vizibilă, pentru că oricare dintre ele o poate suprascrie:

ip -6 route get 2606:4700:4700::1111
ip -6 rule show
ip -6 route show table all

Un prefix mai specific este motivul obișnuit pentru care o destinație rămâne în afara tunelului în timp ce restul rămâne înăuntru, iar o regulă de politică poate face același lucru cu prioritate mai mare decât orice rută. Citește și metrica, pentru că două intrări pentru același prefix se decid după metrică, nu după ordinea lor pe ecran. În Windows lista echivalentă este Get-NetRoute -AddressFamily IPv6, sortată după metrică pentru a corespunde ordinii deciziei. O regulă care pare corectă în tabel poate totuși pierde în fața unei reguli de politică cu număr mai mic, de aceea lista de reguli stă în același gest cu lista de rute.

De unde vine politica IPv6 a clientului

Un client poate fi construit ca să ducă v6 prin tunel, să îl refuze sau să permită o excepție numită, iar aceste trei intenții dau trei rezultate corecte diferite. Citește profilul și documentația clientului însuși înainte de a numi o observație scurgere, pentru că un client care blochează v6 în timp ce sistemul de operare încă trimite descoperirea vecinilor pe legătura fizică se comportă așa cum a fost proiectat.

O aplicație exclusă deliberat din tunel este un caz diferit de o familie pe care tunelul nu a purtat-o niciodată. Prima este o decizie despre un program, a doua este un gol în acoperire, iar reparația diferă în consecință. Citește lista de programe excluse a clientului înainte de a căuta o rută care nu ar fi trebuit să existe niciodată.

Observație îngustă, când tabelul nu este de acord

Când căutarea rutei este ambiguă, o singură observație de interfață pe gazdă o poate lămuri, dar numai dacă este îndreptată spre întrebare. Traficul către punctul final al VPN-ului însuși va traversa adaptorul fizic prin proiectare; ce contează este dacă fluxul aplicației, adresat cu totul altundeva, apare și acolo. Filtrează captura pe destinația pe care o testezi în loc să colectezi tot.

O captură largă expune mult mai mult trafic personal decât cere acea singură întrebare. Răspunde și mai puțin clar, pentru că fluxul care te interesează ajunge îngropat într-un șuvoi de conexiuni fără legătură. Filtrează pe destinația testată, oprește-te după câteva pachete și șterge captura.

Trei moduri de a închide golul

Du familia prin tunel, blocheaz-o în client când tunelul nu o poate purta, sau înregistrează o excepție deliberată cu un proprietar și o dată de revizuire. Fiecare este de apărat, iar singurul lucru care nu este de apărat este să lași alegerea implicită, pentru că o alegere implicită este exact ceea ce este scurgerea. Dacă tunelul nu are deloc ieșire v6, refuzul v6 în client este și cinstit, și testabil. Ce contează este ca alegerea să fie scrisă unde o va găsi următoarea persoană, nu dedusă din comportament șase luni mai târziu.

Repetă verificarea după o reconectare și după mutarea între rețele, pentru că o rută instalată pentru legătura anterioară poate supraviețui schimbării. Apoi notează destinația, ruta selectată, politica clientului și familia folosită de test, ca următoarea persoană să citească o decizie în loc să o derive din nou. RFC 7359 documentează scurgerea pe stivă dublă ca problemă de proiectare și nu ca defect, și este referința de citat când cineva susține că un tunel v4 funcțional acoperă tot.