Client VPN pe un server LAN: de ce răspunsurile pleacă pe calea greșită

Simptomele urmează o singură formă: un host funcționează, apoi se conectează la un VPN ca client, iar acum clienții LAN îl ating în timp ce răspunsurile lui dispar. O captură pe host arată că răspunsurile pleacă prin dispozitivul tunelului în loc de interfața LAN. Nimic din tunel nu este stricat, iar corecția este o rută, nu o reconectare. Parcurgeți cele patru verificări de mai jos în ordine și opriți-vă la prima care eșuează.

Un răspuns este un pachet nou, nu o întoarcere

Ajută să renunțați la ideea că un răspuns se întoarce pe calea pe care a mers o cerere. Rutarea se decide pe pachet, pe direcție, pe hostul care trimite. O cerere care a sosit de la 10.64.0.23 în interiorul tunelului nu creează nicio cale de întoarcere; când hostul răspunde, acel răspuns este comparat cu tabela ca pachet nou și pleacă pe ruta care câștigă.

De aceea un client cu tunel complet pe o mașină care servește și un LAN produce o defecțiune atât de derutantă. Clientul instalează o rută implicită, sau cele două jumătăți de rută implicită pe care le preferă unii clienți, iar răspunsul către un client LAN se potrivește acum cu tunelul. Merge la furnizor, care nu are niciun motiv să îl transmită mai departe, iar clientul LAN vede un timp limită deși hostul este pornit și răspunde local. Captura face asta evident, iar tabela de rutare o explică.

Țineți minte două subrețele în timp ce citiți restul. Una este grupul de adrese VPN din care vin clienții la distanță, în acest exemplu 10.64.0.0/24. Cealaltă este LAN-ul care trebuie să continue să funcționeze, 172.16.24.0/24 cu routerul la 172.16.24.1. Bugul este că traficul dintre ele este decis de ruta implicită.

Demonstrați cu captura și cu interogarea

Înainte de a schimba ceva, confirmați ce dispozitiv va folosi răspunsul. O interogare este mai rapidă decât o captură și răspunde exact la întrebarea la care va răspunde nucleul când pachetul este construit.

ip route get 10.64.0.23 from 172.16.24.10
tcpdump -ni any -c 6 icmp

Citiți răspunsul în două părți. Dacă numește dev tun0, hostul va încapsula răspunsul și îl va preda furnizorului, iar clientul LAN nu îl va vedea niciodată. Dacă numește dev eth0 dar clientul tot ajunge la timp limită, ruta este deja corectă și pachetul este aruncat mai târziu, ceea ce este altă problemă cu altă corecție.

Captura din același pas rezolvă îndoiala pe care un ping nu o poate rezolva. Un ecou de răspuns care ajunge la clientul LAN dovedește că o cale funcționează, nu care interfață l-a purtat, așa că faceți captura pe hostul însuși și urmăriți pe unde ies cadrele. O imprimantă din aceeași subrețea continuă să răspundă, pentru că ruta ei directă este mai specifică decât ruta implicită a tunelului. Un port redirecționat eșuează exact ca orice alt flux, pentru că tabela alege interfața, iar conexiunea nu.

Instalați cea mai îngustă rută care depășește tunelul

Decide lungimea prefixului, nu metrica, așa că o rută pentru grupul de clienți prin routerul LAN câștigă în fața oricărei rute implicite pe care o instalează clientul VPN. Nu este nevoie de chirurgie a metricii, iar ruta implicită poate rămâne exact acolo unde a pus-o clientul.

ip route replace 10.64.0.0/24 via 172.16.24.1 dev eth0
ip route get 10.64.0.23 from 172.16.24.10

Folosiți replace în loc de add, pentru că un client care se reconectează va fi instalat deja propria intrare, iar un al doilea add eșuează cu o eroare de rută existentă care se citește ca o problemă de permisiuni. Pe un host Windows echivalentul este route add 10.64.0.0 mask 255.255.255.0 172.16.24.1 -p, unde -p păstrează intrarea între reporniri, întrucât clientul poate reconstrui tabela când tunelul revine. Pe un host Windows actual echivalentul acceptat este New-NetRoute -DestinationPrefix 10.64.0.0/24 -NextHop 172.16.24.1 -InterfaceAlias Ethernet -PolicyStore PersistentStore, iar comanda route mai veche este păstrată ca formă moștenită.

Un detaliu decide dacă acest lucru este corect sau doar plauzibil: următorul salt trebuie să fie routerul care deține într-adevăr calea înapoi la clienți. Direcționarea rutei către o adresă la care se ajunge chiar prin tunel creează o buclă care se manifestă ca pierdere intermitentă în loc de o defecțiune curată. Confirmați că următorul salt este în subrețeaua LAN înainte de a valida linia.

Păstrați răspunsul după o reconectare

O rută adăugată manual supraviețuiește cel mult până la reconectarea următoare. Dacă grupul de clienți este dinamic, fixați-l în configurația serverului pentru ca prefixul pe care l-ați rutat să rămână prefixul pe care îl primesc clienții; altfel intrarea indică un interval gol și simptomul revine săptămâni mai târziu fără o cauză evidentă. Scrierea rutei în scriptul up al clientului însuși este cealaltă opțiune fiabilă, pentru că rulează după ce clientul a rescris tabela.

Un firewall cu stare poate încă învinge o rută corectă. Dacă captura arată acum că răspunsul pleacă prin eth0 și clientul tot ajunge la timp limită, verificați dacă hostul aruncă pachetul înainte de a-l trimite. Filtrarea strictă a căii inverse și net.ipv4.conf.all.rp_filter setat la 1 aruncă pachetele a căror sursă nu ar fi rutată înapoi prin interfața pe care au sosit, iar acesta este exact cazul asimetric pe care tocmai l-ați creat și apoi l-ați corectat, iar starea conntrack spune aceeași poveste pentru porturile redirecționate.

Ultima verificare este cea pe care oamenii o sar: repetați interogarea după ce tunelul a fost jos și a revenit. Patru valori ar trebui să corespundă cu ce ați notat: destinația, următorul salt, dispozitivul și sursa aleasă. Dacă vreunul s-a mișcat, clientul a rescris tabela și corecția aparține hook-urilor lui, nu istoricului unui shell.