VPN-ul blochează LAN-ul local pe Windows: rută sau politică a clientului?

O imprimantă, un NAS sau o mașină de dezvoltare de pe propriul birou încetează să răspundă în momentul în care VPN-ul de serviciu se conectează. Uneori o comandă de rută rezolvă în câteva secunde; alteori aceeași rută este corectă și pachetele dispar totuși, ceea ce înseamnă că priviți o altă problemă cu un simptom similar. Decizia se reduce la trei întrebări, iar adresarea lor în ordinea greșită este motivul pentru care oamenii petrec o seară întreagă ștergând și adăugând din nou rute.

Trei întrebări înainte de orice comandă

Întâi: există o intrare pentru prefixul local și indică ea adaptorul fizic? Al doilea: primește clientul la conectare o permisiune sau un refuz pentru rețeaua locală de la gateway? Al treilea: aveți nevoie doar de acces de ieșire către LAN, sau ceva de pe internet trebuie să ajungă și la un serviciu care rulează pe mașina dumneavoastră?

Prima întrebare separă o defecțiune de rutare de una de filtrare. A doua spune dacă o corectare de rută are voie să funcționeze. A treia schimbă reparația: o rută repară traficul de ieșire, în timp ce un serviciu de intrare inaccesibil este de obicei o problemă de legare a ascultătorului și de cale de întoarcere pe care o rută o agravează.

Întrebarea unu: rută, filtru sau nume

Citiți tabelul înainte de a adăuga ceva. Indexul interfeței contează, pentru că fiecare comandă de rută de mai jos este ancorată în el:

route print -4
Get-NetRoute -DestinationPrefix 192.168.1.0/24 | Format-Table InterfaceIndex,NextHop,RouteMetric

O subrețea conectată direct păstrează de obicei o rută on-link chiar și cu tunelul activ, așa că o intrare poate exista și traficul poate eșua în continuare. Această combinație este semnătura unui filtru care rulează după rutare și este cazul în care o a doua rută, mai specifică, nu schimbă absolut nimic.

Testați separat după adresă și după nume. Dacă ping 192.168.1.50 răspunde și net view 192.168.1.50 nu, tabelul de rutare nu a fost niciodată problema: tunelul a schimbat resolverul și numele local nu mai este rezolvat. Adăugarea unei rute pentru asta este muncă risipită.

Întrebarea doi: permite gateway-ul accesul la LAN-ul local?

Un client comercial instalează mai mult decât rute. Primește o politică la conectare, iar acea politică poate include o permisiune explicită pentru rețeaua locală. În implementările Cisco IPsec politica de grup poartă setarea de split-tunneling și un indicator separat pentru accesul la LAN-ul local; caseta de selectare din client este o cerere pe care gateway-ul o poate refuza. În AnyConnect profilul controlează listele de includere și excludere split și aceeași permisiune. Pe Windows RRAS echivalentele sunt opțiunea de gateway implicit din profil plus rutele statice pe care le atribuie serverul.

Când indicatorul este oprit, comportamentul documentat este că clientul blochează traficul către subrețeaua conectată direct, deși există o rută validă, mai specifică. De aceea și rutele pe care clientul nu le deține pot dispărea la câteva secunde după ce le adăugați: clientul reconstruiește starea pe care i s-a spus să o construiască, nu se luptă cu dumneavoastră.

Jurnalul clientului înregistrează decizia la conectare, iar citirea lui este mai rapidă decât orice experiment pe mașină. Dacă jurnalul spune că accesul local este blocat, opriți-vă: nicio corectare din linia de comandă nu supraviețuiește, iar singurele căi rămase sunt o schimbare de politică, atingerea resursei prin tunel sau izolarea clientului într-o mașină virtuală și lăsarea gazdei în rețeaua locală.

Întrebarea trei: de ce direcție aveți nevoie?

Traficul de ieșire către un dispozitiv apropiat este o chestiune de rutare. Îndreptați prefixul LAN către gateway-ul local cu o metrică suficient de mică pentru a învinge ruta implicită a tunelului:

route add 192.168.1.0 mask 255.255.255.0 192.168.1.1 metric 1 if 12
route add 192.168.1.50 mask 255.255.255.255 192.168.1.1 -p

A doua formă fixează un singur dispozitiv, ceea ce doriți când o adresă este întreaga cerință. Echivalentul netsh înregistrează aceeași decizie după numele interfeței, nu după index:

netsh interface ipv4 add route prefix=192.168.1.0/24 interface=12 nexthop=192.168.1.1 store=persistent

Comenzile de rută eșuează cu Parametrul este incorect când adresa și masca nu se potrivesc, de exemplu o adresă de gazdă cu mască /24. Folosiți adresa de rețea pentru o rută de subrețea și o mască de gazdă pentru o singură gazdă.

Traficul de intrare este diferit. Un server VNC sau SSH pe aceeași mașină devine inaccesibil când răspunsurile la o conexiune de intrare ies prin gateway-ul VPN și nu se mai întorc. Verificați pe ce ascultă serviciul înainte de a atinge rutele:

netstat -ano | findstr :5900

Un ascultător legat de o adresă anume nu va răspunde pe cealaltă interfață. Legarea lui de toate interfețele este o decizie deliberată, luată împreună cu o regulă de firewall limitată la rețeaua în care aveți încredere. Abia după aceea reparația rutei restaurează calea de întoarcere.

Aplicați cea mai mică schimbare potrivită

Cealaltă mișcare obișnuită este debifarea „Folosește gateway-ul implicit în rețeaua la distanță” din proprietățile avansate IPv4. Aceasta menține traficul de internet local, dar face două lucruri deodată: VPN-ul nu mai este calea implicită, iar clientul nu mai primește rute pentru rețeaua la distanță, inclusiv multicast. Debifați și LAN-ul la distanță dispare, cu excepția cazului în care serverul împinge prefixele la distanță specifice de care are nevoie fiecare client.

Această asimetrie decide ordinea lucrului. Dacă partea la distanță trebuie să rămână pe deplin accesibilă, împingeți subrețelele la distanță de la server și lăsați implicitul local în pace. Dacă nu puteți schimba serverul, adăugați o rută persistentă către prefixul la distanță prin adresa atribuită de tunel și verificați cu route print că prefixul indică interfața VPN în timp ce implicitul indică încă gateway-ul fizic.

Apoi confirmați că reparația supraviețuiește unei reconectări, pentru că rutele nepersistente mor odată cu adaptorul, iar un script care rulează după fiecare conectare este locul cinstit pentru ele. Testați un dispozitiv local și o resursă la distanță în aceeași sesiune, deconectați, reconectați și testați din nou. Dacă dispozitivul local eșuează în continuare în timp ce ruta pare corectă, reveniți la întrebarea doi: clientul filtrează, iar răspunsul este o schimbare de politică și nu o a doua rută concurentă.