Lokalno omrežje ni dosegljivo, ko je VPN povezan? Štiri preverjanja

Predor se dvigne, intranet se pojavi, tiskalnik pa preneha odgovarjati. V omrežju LAN se ni nič pokvarilo; odjemalec je spremenil pot, ki jo uporablja za naslove, ki jih ne obravnava več kot lokalne. Pojdite skozi štiri preverjanja spodaj po vrsti in se ustavite, ko eno pokaže konkretno neujemanje, ker ima isti simptom štiri pogoste vzroke in le enega od njih odpravi urejanje VPN-a.

Najprej poglejte usmerjevalno tabelo, ki jo je namestil odjemalec

Odprite usmerjevalno tabelo odjemalca, medtem ko je VPN povezan. V Linuxu uporabite ip route, v Windowsu route print ali Get-NetRoute, v macOS pa netstat -rn. Iščete privzeto pot skozi predor in to, kaj se je zgodilo s fizično privzeto potjo.

Odjemalec s polnim predorom pogosto doda dve polprivzeti poti, 0.0.0.0/1 in 128.0.0.0/1, namesto da bi zamenjal 0.0.0.0/0. Prvotna privzeta pot ostane vidna, a izgubi vsako iskanje, zato je tabela lahko videti nedotaknjena, medtem ko se ves promet zunaj podomrežja premakne. Če odjemalec VPN ponuja možnost razdeljenega predora in politika to dovoljuje, je to najčistejša poprava.

Če mora predor ostati privzet, pripnite lokalno podomrežje. V Linuxu pot navaja fizični vmesnik in prehod; v Windowsu dodajte -p, da bo trajna, in številko vmesnika preberite iz route print, namesto da bi jo ugibali:

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

Pripeta pot se drži le toliko časa, dokler se naslov, ki ga navaja, ne spremeni. Prenosnik, ki pri vsaki povezavi dobi novo številko omrežne kartice Wi-Fi, bo pravilo znova prekršil, zato preverite naslov vmesnika, preden sklenete, da poprava ni uspela.

Drugič, potrdite, da je bil naslov lokalni že od začetka

Če cilj leži v povezanem podomrežju, privzeta pot predora nikoli ne velja in VPN ni vzrok. Tiskalnik na 192.168.1.40 na odjemalcu s 192.168.1.0/24 uporablja povezano pot; če ta naslov ne deluje, poglejte napravo, stikalo ali požarni zid na odjemalcu, ne VPN.

Primer, ki zavede ljudi, je javni naslov za lokalni strežnik. Znotraj omrežja LAN doseganje naslova WAN usmerjevalnika in vrnitev zahteva hairpin NAT, mnogi usmerjevalniki pa ga za posredovanje vrat preprosto ne izvedejo. Preizkusite zasebni naslov poleg javnega. Če zasebni deluje in javni ne, je VPN samo razkril omejitev NAT, ki je obstajala že prej.

Ime gostitelja to poslabša. Če se lokalno ime zdaj razreši v javni naslov, bo odjemalec še naprej poskušal pot, ki se ne more vrniti. Za preizkus uporabite zasebni naslov in nato popravite ime, namesto da bi dodali še eno posredovanje vrat.

Tretjič, poglejte, kdo zdaj odgovarja na imena

Podjetniški resolver pozna intranet in običajno ne ve ničesar o imenu gostitelja NAS, imenu Bonjour tiskalnika ali lokalnem vzdevku usmerjevalnika. Ko VPN potisne svoje strežnike DNS, se ta imena prenehajo razreševati, čeprav so njihovi naslovi še dosegljivi. Vprašajte za ime neposredno in primerjajte odgovor z naslovom, za katerega veste, da ga ima naprava.

V Linuxu resolvectl query nas.local pokaže, kateri resolver je odgovoril. V Windowsu nslookup nas.local navede strežnik, ipconfig /all pa pokaže vrstni red resolverjev. Če lokalno pripono zdaj obravnava podjetniški resolver, to pripono preusmerite nazaj na lokalni resolver ali za napravo uporabite naslov IP.

Odkrivanje je ločena plast. mDNS in oddajanje ne prečkata usmerjenega predora, zato je naprava lahko dosegljiva po naslovu, medtem ko ime ostane nevidno. Odbojnik ali lokalni vnos DNS to reši; pot ne.

Četrtič, preverite, ali je tudi drugi stroj v VPN-u

Ko stroj, ki ga želite doseči, tudi poganja odjemalca VPN, lahko vaša seja prispe, medtem ko odgovor odhaja skozi drugi predor. Nastane povezava, ki se vzpostavi in nato obtiči, ali poskus RDP in SSH, ki na vaši strani poteče brez napake. Preverite usmerjevalno tabelo drugega gostitelja in njegovo privzeto pot, preden obtožite svojega odjemalca.

Preverite tudi naslov, na katerem storitev posluša. Poslušalec, vezan le na naslov predora, sprejema povezave iz VPN-a in jih zavrača iz omrežja LAN, tudi ko je usmerjanje popolno. To je konfiguracija storitve, ne omrežna pot, in je pogosta na upravljavskih vmesnikih, ki so bili zaklenjeni na naslov VPN.

Ohranjajte upravljavsko pot, ki ni odvisna od predora: statična pot z vašim izvornim omrežjem, drug vmesnik, priključen v LAN, ali konzola, ki predor popolnoma obide. Načrtovati to pot po padcu seje je veliko težje kot jo dodati pred naslednjo povezavo.

Uporabite popravo, ki ustreza neuspešnemu preverjanju

Če je usmerjevalna tabela pokazala polprivzeto prevzem, izberite razdeljeni predor, ko politika dovoljuje, in pripeto lokalno pot, ko ne. Če se je naslov izkazal za javnega, preklopite preizkus in ime na zasebni naslov. Če je resolver zamenjal roke, se omejite na lokalno pripono ali uporabite naslov. Če je drugi gostitelj v predoru, popravite njegovo povratno pot ali vezavo poslušalca.

Spremenite eno stvar in nato ponovite isto preverjanje. Pot, dodana za napačno podomrežje, pripona resolverja s tipkarsko napako in pripeta pot na vmesniku, ki dobiva nove številke, so videti kot prvotna okvara. Ponovitev je tisto, kar loči popravo od naključja.

Zapišite pot, naslov in resolver, ki so delovali, ko je bil VPN povezan. Naslednja ponovna povezava bo spremenila vsaj enega od njih, in zapis bo naslednjo motnjo spremenil v kratko primerjavo namesto nove preiskave.