Paikallinen verkko ei ole tavoitettavissa VPN:n ollessa yhdistettynä? Neljä tarkistusta

Tunneli nousee, intranet ilmestyy ja tulostin lakkaa vastaamasta. Mikään paikallisverkossa ei ole hajonnut; asiakas on vaihtanut reitin, jota se käyttää osoitteille, joita se ei enää pidä paikallisina. Käy alla olevat neljä tarkistusta järjestyksessä läpi ja pysähdy, kun jokin tuottaa konkreettisen ristiriidan, sillä samalla oireella on neljä yleistä syytä ja vain yksi niistä korjataan VPN:ää muokkaamalla.

Ensiksi, katso reititystaulua, jonka asiakas asensi

Avaa asiakkaan reititystaulu, kun VPN on yhdistettynä. Linuxissa käytä ip route, Windowsissa route print tai Get-NetRoute ja macOS:ssä netstat -rn. Etsit oletusreittiä tunnelin kautta ja sitä, mitä fyysiselle oletusreitille tapahtui.

Koko tunnelin asiakas lisää usein kaksi puolikasta oletusreittiä, 0.0.0.0/1 ja 128.0.0.0/1, sen sijaan että se korvaisi 0.0.0.0/0. Alkuperäinen oletusreitti pysyy näkyvissä mutta menettää jokaisen haun, minkä vuoksi taulu voi näyttää ehjältä, vaikka kaikki aliverkon ulkopuolinen liikenne siirtyy. Jos VPN-asiakas tarjoaa jaetun tunnelin vaihtoehdon ja käytäntö sallii sen, se on puhtain korjaus.

Jos tunnelin on jäätävä oletusreitiksi, kiinnitä sen sijaan paikallinen aliverkko. Linuxissa reitti nimeää fyysisen liitännän ja yhdyskäytävän; Windowsissa lisää -p, jotta se on pysyvä, ja lue liitännän numero route print-kohdasta sen sijaan että arvaisit sen:

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

Kiinnitetty reitti pysyy vain niin kauan kuin sen nimeämä osoite pysyy samana. Kannettava, joka numeroi Wi-Fi-sovittimensa uudelleen joka yhteydellä, rikkoo säännön taas, joten tarkista liitännän osoite ennen kuin päätät, että korjaus epäonnistui.

Toiseksi, varmista että osoite oli paikallinen alun perin

Jos kohde on yhdistetyn aliverkon sisällä, tunnelin oletusreittiä ei koskaan sovelleta eikä VPN ole syy. Tulostin osoitteessa 192.168.1.40 asiakkaassa, jolla on 192.168.1.0/24, käyttää yhdistettyä reittiä; jos se osoite epäonnistuu, katso laitetta, kytkintä tai asiakkaan palomuuria VPN:n sijaan.

Tapaus, joka huijaa ihmisiä, on julkinen osoite paikalliselle palvelimelle. Paikallisverkon sisältä reitittimen WAN-osoitteeseen pääseminen ja takaisin tuleminen vaatii hairpin-NAT:n, eivätkä monet reitittimet yksinkertaisesti toteuta sitä portinohjauksille. Testaa yksityistä osoitetta julkisen vieressä. Jos yksityinen osoite toimii ja julkinen ei, VPN toi esiin vain NAT-rajoituksen, joka oli jo olemassa.

Isäntänimi pahentaa asiaa. Jos paikallinen nimi ratkeaa nyt julkiseen osoitteeseen, asiakas jatkaa sellaisen reitin yrittämistä, joka ei voi palata. Käytä testiin yksityistä osoitetta ja korjaa sitten nimi sen sijaan että lisäisit vielä yhden portinohjauksen.

Kolmanneksi, katso kuka vastaa nimiin nyt

Yrityksen nimipalvelin tuntee intranetin eikä yleensä tiedä mitään NAS-isäntänimestä, tulostimen Bonjour-nimestä tai reitittimen paikallisesta aliaksesta. Kun VPN työntää DNS-palvelimensa, ne nimet lakkaavat ratkeamasta, vaikka niiden osoitteet ovat yhä tavoitettavissa. Kysy nimeä suoraan ja vertaa vastausta osoitteeseen, jonka tiedät laitteella olevan.

Linuxissa resolvectl query nas.local näyttää, mikä nimipalvelin vastasi. Windowsissa nslookup nas.local nimeää palvelimen ja ipconfig /all näyttää nimipalvelimien järjestyksen. Jos paikallista suffiksia hoitaa nyt yrityksen nimipalvelin, joko ohjaa suffiksi takaisin paikalliselle nimipalvelimelle tai käytä laitteen IP-osoitetta.

Löytäminen on erillinen kerros. mDNS ja lähetys eivät ylitä reititettyä tunnelia, joten laite voi olla tavoitettavissa osoitteella, kun taas sen nimi pysyy näkymättömänä. Heijastin tai paikallinen DNS-merkintä ratkaisee sen; reitti ei.

Neljänneksi, tarkista onko toinenkin kone VPN:ssä

Kun kone, johon haluat päästä, ajaa myös VPN-asiakasta, istuntosi voi saapua samalla kun sen vastaus lähtee toisen tunnelin kautta. Se tuottaa yhteyden, joka muodostuu ja sitten juuttuu, tai RDP- ja SSH-yrityksen, joka aikakatkaistaan ilman virhettä sinun puolellasi. Tarkista toisen isännän reititystaulu ja sen oletusreitti ennen kuin syytät asiakastasi.

Tarkista myös osoite, jossa palvelu kuuntelee. Vain tunnelin osoitteeseen sidottu kuuntelija hyväksyy yhteyksiä VPN:stä ja hylkää ne paikallisverkosta, vaikka reititys olisi täydellinen. Se on palvelun kokoonpano, ei verkkoreitti, ja se on yleinen hallintaliittymissä, jotka lukittiin VPN-osoitteeseen.

Pidä yllä hallintareitti, joka ei riipu tunnelista: staattinen reitti, joka nimeää lähiverkkosi, toinen paikallisverkkoon kytketty liitäntä tai konsoli, joka ohittaa tunnelin kokonaan. Sellaisen reitin suunnitteleminen istunnon katkeamisen jälkeen on paljon vaikeampaa kuin sen lisääminen ennen seuraavaa yhteyttä.

Käytä korjausta, joka vastaa epäonnistunutta tarkistusta

Jos reititystaulu näytti puolikkaan oletusreitin kaappauksen, valitse jaettu tunneli kun käytäntö sallii ja kiinnitetty paikallinen reitti kun ei. Jos osoite osoittautui julkiseksi, vaihda testi ja nimi yksityiseen osoitteeseen. Jos nimipalvelin vaihtui, rajaa paikallinen suffiksi tai käytä osoitetta. Jos toinen isäntä on tunnelissa, korjaa sen paluureitti tai kuuntelijan sidonta.

Muuta yhtä asiaa ja toista sitten sama tarkistus. Väärälle aliverkolle lisätty reitti, kirjoitusvirheen sisältävä nimipalvelimen suffiksi ja kiinnitetty reitti liitännässä, joka numeroi uudelleen, näyttävät kaikki alkuperäiseltä vialta. Toisto on se, mikä erottaa korjauksen sattumasta.

Kirjoita ylös reitti, osoite ja nimipalvelin, jotka toimivat VPN:n ollessa yhdistettynä. Seuraava uudelleenyhdistäminen muuttaa ainakin yhtä niistä, ja muistiinpano tekee seuraavasta katkoksesta lyhyen vertailun uuden tutkimuksen sijaan.