De ce un VPN cu tunel complet îți ascunde VLAN-urile locale rutate

Comutatorul „permite rețeaua locală” dintr-un client VPN sună ca și cum ar acoperi tot din clădire. În practică, de obicei adaugă câteva excepții pentru adrese private la ruta implicită a tunelului și se oprește acolo. VLAN-ul tău de stocare rămâne accesibil doar dacă o rută pentru acel prefix specific supraviețuiește sosirii tunelului, iar pe mulți clienți nu supraviețuiește.

Asta este o întrebare de rutare, nu o setare VPN, ceea ce este o veste bună: are un răspuns concret.

Ce acoperă de fapt permiterea rețelei locale

Clienții implementează opțiunea diferit. Unii adaugă rute pentru subrețeaua de care este legată mașina, unii adaugă intervalele RFC 1918, iar câțiva exclud doar gateway-ul implicit. Niciunul nu știe că routerul biroului tău deservește și un VLAN de stocare, un segment de laborator sau o subrețea de imprimante, pentru că acele prefixe nu sunt în rețeaua pe care clientul o poate vedea. Citește documentația clientului însuși pentru comportamentul exact, în loc să presupui că eticheta descrie topologia ta.

Diferența contează cel mai mult într-un design cu tunel complet, unde clientul înlocuiește intenționat ruta implicită pentru ca tot traficul să treacă prin VPN. Acesta este scopul întregului design și tot el face ca rețelele locale rutate să dispară. Nu au fost niciodată acoperite de o rută proprie; mergeau pe ruta implicită care tocmai a fost înlocuită. Un client nu poate ruta ceea ce nu știe că există și învață doar prefixele legate de propria interfață. Orice altceva trebuie descris de cineva care cunoaște topologia.

Rutele conectate se opresc la primul router

O stație de lucru la 192.168.10.20/24 cu gateway 192.168.10.1 primește automat o rută conectată pentru 192.168.10.0/24. VLAN-ul de stocare la 192.168.20.0/24 este un alt prefix, accesibil doar prin acel gateway, iar stația nu are nicio rută pentru el în afara celei implicite. Înainte ca tunelul să apară, ruta implicită obișnuită trimite traficul de stocare către 192.168.10.1 și totul funcționează.

Când VPN-ul instalează o rută implicită de tunel complet, pachetele pentru 192.168.20.1 urmează noua rută implicită în tunel. Gateway-ul îndepărtat nu are habar unde se află acel prefix, așa că le aruncă sau le trimite într-un loc inutil. Nimic nu era configurat greșit pe VLAN-ul de stocare; calea lui era împrumutată, iar împrumutul a fost cerut înapoi.

Tentația este să apelezi la o excepție largă, cum ar fi o pereche de rute /1 sau o a doua rută implicită. Rezistă. Cu cât excepția este mai îngustă, cu atât este mai ușor să o explici, să o auditezi și să o elimini când rețeaua se schimbă.

Pune excepția în tabelul care câștigă

În interiorul unui singur tabel de rutare, un /24 învinge un /0 sau un /1 prin potrivirea celui mai lung prefix, deci o rută specifică spre VLAN-ul de stocare prin gateway-ul local este suficientă, cu condiția ca tabelul să fie consultat. Pe Linux, forma obișnuită este scurtă:

ip route add 192.168.20.0/24 via 192.168.10.1 dev eth0

Rutarea bazată pe politici complică această garanție. O regulă anterioară poate trimite traficul către un tabel a cărui rută implicită duce în tunel, iar tabelul principal care conține /24-ul tău nu mai este niciodată atins. Verifică regulile înainte de a presupune că ruta este autoritară, pentru că o intrare cu aspect corect în tabelul greșit explică o defecțiune care arată ca o rută stricată.

Apoi fă intrarea persistentă prin mecanismul suportat de client sau prin managerul de rețea care deține interfața. O rută tastată în prompt dispare la următoarea reconectare, iar o rută legată de un singur gateway Wi-Fi nu este portabilă către următoarea rețea pe care o vizitează laptopul.

Numele și politica nu urmează rutele

Repararea rutei restaurează pachetele, nu numele. Dacă dispozitivele locale sunt rezolvate printr-un resolver împins care nu știe nimic despre ele, montarea eșuează în continuare chiar dacă adresa este accesibilă. Numele locale au nevoie de o aranjare DNS locală sau divizată, iar aceea este o decizie separată de excepția de rutare.

Politica este din nou separată. Filtrul de acces local al unui client VPN poate interzice intenționat traficul către intervalele private, iar o rută nu anulează acea regulă. Pe o rețea nesigură, o adresă privată nu este nici dovada că destinația este serverul tău de stocare, așa că excepția ar trebui să fie la fel de specifică precum ruta.

Un contract pe care îl poți preda

Designul final ar trebui să se citească ca o listă scurtă: traficul general de internet urmează tunelul, iar aceste prefixe locale numite își păstrează calea prin routerul local. Notează prefixele, următorul hop și sufixul DNS care le însoțește, și ține lista suficient de scurtă încât cineva să o poată verifica fără să citească un tabel de rutare.

Ai grijă la suprapunerea dintre intervalele locale și cele îndepărtate. Un VLAN de stocare care împarte un prefix cu ceva din spatele VPN-ului va fi rezolvat către ruta mai specifică, iar comportamentul rezultat este confuz într-un mod care pare intermitent. Renumerotarea unei părți este de obicei mai ieftină decât depanarea acelei ambiguități pentru totdeauna.

Testează contractul de două ori: o dată cu tunelul pornit și o dată cu el oprit. Dacă calea locală funcționează doar într-una dintre stări, excepția nu este încă un contract.