De ce o rută de tunel complet taie serverul care o transportă

Activați un tunel complet și fiecare destinație aparține acum interfeței VPN, inclusiv mașina care îl termină. Pachetele exterioare care transportă tunelul sunt adresate acelei mașini, așa că ruta ajunge să consume transportul de care depinde. O rută specifică suplimentară rezolvă problema, iar motivul merită înțeles. Fără acel motiv, următoarea reconstrucție reintroduce defectul.

O rută care își mănâncă propriul transport

Encapsularea înfășoară fiecare pachet într-un al doilea antet. Cel exterior este adresat de la adresa fizică locală la adresa publică a serverului și trebuie să traverseze legătura fizică înainte ca vreun tunel să poată exista.

Acum lăsați căutarea acelei adrese publice să aleagă tunelul. Pentru a trimite pachetul, mașina trebuie să îl encapsuleze, ceea ce cere o rută către aceeași adresă, iar aceasta returnează tunelul. Clienții tratează asta într-unul din două moduri. Unul prudent refuză să instaleze ruta implicită și raportează o eroare, în timp ce unul mai puțin prudent raportează succes și apoi nu mișcă nimic. Eșecul tăcut este cel care costă o după-amiază.

Potrivirea celui mai lung prefix decide căutarea înainte de a fi consultată vreo metrică, așa că o rută către o singură adresă depășește orice rută implicită de pe mașină. Acesta este întregul mecanism din spatele reparației.

Instalați excepția înaintea celei implicite

Creați o rută către o singură adresă pentru server, cu poarta fizică drept următorul salt, înainte ca ruta implicită să se miște. Ordinea contează: instalarea ei mai târziu înseamnă să trăiești cu un tunel stricat în timp ce tastați.

Majoritatea clienților fac asta fără să li se ceară. OpenVPN caută adresa îndepărtată și o fixează înainte de a rescrie poarta implicită, iar opțiunea sa route-delay există pentru platformele unde acea secvență concurează. wg-quick ia o cale complet diferită, marcând pachetele și consultând o regulă de politică în loc să adauge o excepție. Mecanisme diferite, aceeași cerință: pachetul exterior trebuie să scape din tunelul pe care îl creează.

ip route add 203.0.113.10/32 via 192.168.1.1 dev eth0
ip route get 203.0.113.10

Ieșirea căutării este testul de acceptare. Trebuie să numească dispozitivul fizic și următorul salt fizic. Un dispozitiv de tunel în acel răspuns înseamnă că excepția lipsește sau a fost plasată după ceva ce o suprascrie.

Imaginea în oglindă pe server

Aceeași capcană așteaptă pe cealaltă parte, inversată. Dați serverului o rută implicită printr-un alt tunel, sau împingeți-i o rută care acoperă adresele publice ale clienților, și răspunsurile sale capătă obiceiul direcției greșite.

Imaginați-vă un client care se conectează și trimite o cerere. Răspunsul este adresat adresei publice a acelui client, care acum corespunde unei rute de tunel, așa că pleacă de pe altă interfață purtând o sursă pe care clientul nu a format-o niciodată. Clientul poate primi acel pachet și totuși să îl arunce, pentru că nimic nu îl leagă de cererea pe care a trimis-o. Porniți de la decizia de rutare a serverului, nu de la expirarea timpului clientului, fiindcă doar una dintre ele arată alegerea reală.

ip route get 198.51.100.44 from 10.90.0.1
ip rule show
sudo tcpdump -ni any host 198.51.100.44

Există trei reparații și nu sunt egale. Fixarea serviciului pe adresa fizică, sau traducerea sursei, ambele ascund decizia de rutare în loc să o corecteze. Trimiterea traficului de răspuns pentru pool-ul tunelului printr-un tabel dedicat corectează cauza, iar celelalte două sunt acceptabile doar cât timp proiectul de rutare este înghețat.

Excepții pe care tunelul continuă să le fure

O mână de sarcini au nevoie de internetul deschis chiar și atunci când tunelul deține ruta implicită, iar fiecare are nevoie de propria excepție. Actualizatorul DNS dinamic este de obicei primul care se strică.

Rezolvă furnizorul, deschide o conexiune și descoperă că propriile pachete călătoresc printr-un tunel a cărui adresă s-a schimbat cu câteva secunde în urmă, așa că actualizarea eșuează sau publică adresa greșită. Trei ieșiri: fixați furnizorul cu o rută de gazdă prin poarta fizică, rulați actualizarea înainte ca tunelul să urce, sau dați actualizatorului un tabel de politică pe care tunelul nu îl atinge niciodată. Sincronizarea timpului are aceeași expunere pe un dispozitiv care pornește fără resolver, iar punctele de validare a certificatelor fac parte din listă din același motiv.

O excepție pe care nimeni nu a scris-o este o excepție pe care următoarea reconstrucție o va arunca în tăcere.

Dovediți-o după o reconectare, nu înainte

Testați trei destinații, nu una: punctul final, o adresă privată în spatele tunelului și o adresă publică dincolo de el. O singură căutare reușită nu spune aproape nimic despre celelalte două.

ip route get 203.0.113.10
traceroute -n 203.0.113.10
ip route get 10.90.0.5
ip route get 1.1.1.1

Apoi reporniți conexiunea, pentru că un client care își reconstruiește tabelul la reconectare va arunca o rută tastată manual. Cu un kill switch activ, verificați că punctul final este permis, altfel tunelul nu poate reveni după o schimbare de rețea și simptomul arată ca o cădere. Păstrați excepția în profil sau în fișierul unit, nu în istoricul shell-ului, ca reconectarea să o recreeze în loc să o șteargă.