Plaaslike netwerk onbereikbaar terwyl die VPN aan is? Vier toetse

Die tonnel kom op, die intranet verskyn, en die drukker hou op antwoord. Niks op die LAN het gefaal nie; die kliënt het die pad verander wat hy gebruik vir adresse wat hy nie meer as plaaslik beskou nie. Stap die vier kontroles hieronder in volgorde deur en stop wanneer een 'n konkrete verskil oplewer, want dieselfde simptoom het vier algemene oorsake en net een daarvan word reggemaak deur die VPN te redigeer.

Eerstens, kyk na die roetetabel wat die kliënt geïnstalleer het

Maak die kliënt se roetetabel oop terwyl die VPN verbind is. Op Linux gebruik ip route, op Windows gebruik route print of Get-NetRoute, en op macOS gebruik netstat -rn. Jy soek 'n verstekroete deur die tonnel en wat met die fisiese verstekroete gebeur het.

'n Voltonnel-kliënt voeg dikwels twee half-verstekroetes by, 0.0.0.0/1 en 128.0.0.0/1, in plaas daarvan om 0.0.0.0/0 te vervang. Die oorspronklike verstekroete bly sigbaar maar verloor elke opsoek, en daarom kan die tabel ongeskonde lyk terwyl alle verkeer buite die subnet beweeg. As die VPN-kliënt 'n opsie vir 'n verdeelde tonnel bied en beleid dit toelaat, is dit die skoonste herstel.

As die tonnel die verstekroete moet bly, bind die plaaslike subnet eerder vas. Op Linux noem die roete die fisiese koppelvlak en die gwadres; op Windows voeg -p by om dit blywend te maak en lees die koppelvlaknommer uit route print eerder as om dit te raai:

sudo ip route add 192.168.1.0/24 via 192.168.1.1 dev wlan0
route add -p 192.168.1.0 MASK 255.255.255.0 192.168.1.1 METRIC 1 IF 12

'n Vasgebinde roete hou net solank die adres wat dit noem dieselfde bly. 'n Skootrekenaar wat sy Wi-Fi-aanpasder by elke koppeling hernommer, sal die reël weer breek, so kyk na die koppelvlakadres voordat jy besluit die herstel het gefaal.

Tweedens, bevestig dat die adres in die eerste plek plaaslik was

As die bestemming binne die gekoppelde subnet lê, geld die tonnel-verstekroete nooit nie en is die VPN nie die oorsaak nie. 'n Drukker by 192.168.1.40 op 'n kliënt met 192.168.1.0/24 gebruik die gekoppelde roete; as daardie adres faal, kyk na die toestel, die skakelaar of die firewall op die kliënt in plaas van die VPN.

Die geval wat mense mislei, is 'n publieke adres vir 'n plaaslike bediener. Van binne die LAN vereis om die router se WAN-adres te bereik en terug te kom 'n haarspeld-NAT, en baie routers implementeer dit eenvoudig nie vir poortaansturings nie. Toets die private adres langs die publieke een. As die private adres werk en die publieke een nie, het die VPN net 'n NAT-beperking blootgelê wat al daar was.

'n Gasheernaam maak dit erger. As die plaaslike naam nou na die publieke adres oplos, sal die kliënt aanhou om die pad te probeer wat nie kan teruglus nie. Gebruik die private adres vir die toets en maak dan die naam reg in plaas daarvan om nog 'n poortaansturing by te voeg.

Derdens, kyk wie antwoord nou op name

'n Korporatiewe resolveerder ken die intranet en gewoonlik niks van 'n NAS-gasheernaam, 'n drukker se Bonjour-naam of 'n router se plaaslike alias nie. Wanneer die VPN sy DNS-bediener druk, hou daardie name op om op te los selfs al is hul adresse steeds bereikbaar. Vra die naam direk en vergelyk die antwoord met die adres wat jy weet die toestel het.

Op Linux wys resolvectl query nas.local watter resolveerder geantwoord het. Op Windows noem nslookup nas.local die bediener, en ipconfig /all wys die volgorde van die resolveerders. As die plaaslike agtervoegsel nou deur die korporatiewe resolveerder hanteer word, stuur daardie agtervoegsel terug na die plaaslike resolveerder of gebruik die IP-adres vir die toestel.

Ontdekking is 'n aparte laag. mDNS en uitsaai steek nie 'n geroteerde tonnel oor nie, so 'n toestel kan per adres bereikbaar wees terwyl sy naam onsigbaar bly. 'n Weerkaatser of 'n plaaslike DNS-inskrywing los dit op; 'n roete doen dit nie.

Vierdens, kyk of die ander masjien ook op 'n VPN is

Wanneer die masjien wat jy wil bereik ook 'n VPN-kliënt laat loop, kan jou sessie aankom terwyl sy antwoord deur die ander tonnel vertrek. Dit lewer 'n verbinding wat vestig en dan vasval, of 'n RDP- en SSH-poging wat uittyd sonder enige fout aan jou kant. Kyk na die ander gasheer se roetetabel en sy verstekpad voordat jy jou kliënt blameer.

Kyk ook na die adres waarop die diens luister. 'n Luisteraar wat net aan die tonneladres gebind is, aanvaar verbindings van die VPN en weier hulle van die LAN, selfs wanneer roetering perfek is. Dit is 'n dienskonfigurasie, nie 'n netwerkpad nie, en dit kom algemeen voor op bestuurskoppelvlakke wat vir die VPN-adres toegesluit is.

Hou 'n bestuurspad wat nie van die tonnel afhang nie: 'n statiese roete wat jou bronnetwerk noem, 'n ander koppelvlak wat aan die LAN gekoppel is, of 'n konsole wat die tonnel heeltemal omseil. Om daardie pad te ontwerp nadat die sessie verloor is, is baie moeiliker as om dit voor die volgende koppeling by te voeg.

Pas die herstel toe wat by die mislukte kontrole pas

As die roetetabel 'n half-verstek-kaping gewys het, kies 'n verdeelde tonnel wanneer beleid dit toelaat en 'n vasgebinde plaaslike roete wanneer dit nie toelaat nie. As die adres publiek geblyk het, skakel die toets en die naam na die private adres oor. As die resolveerder van hande verwissel het, beperk die plaaslike agtervoegsel of gebruik die adres. As die ander gasheer deur 'n tonnel loop, maak sy terugpad of sy luisteraarbinding reg.

Verander een ding en herhaal dan dieselfde kontrole. 'n Roete wat vir die verkeerde subnet bygevoeg is, 'n resolveerder-agtervoegsel met 'n tikfout en 'n vasgebinde roete op 'n koppelvlak wat hernommer, lyk almal soos die oorspronklike fout. Die herhaling is wat 'n herstel van 'n toeval skei.

Skryf die roete, die adres en die resolveerder neer wat gewerk het terwyl die VPN verbind was. Die volgende herverbinding sal ten minste een daarvan verander, en die nota maak die volgende onderbreking 'n kort vergelyking in plaas van 'n nuwe ondersoek.