VPN estää paikallisen lähiverkon Windowsissa: reitti vai asiakaskäytäntö?

Työpöydälläsi oleva tulostin, NAS tai kehityskone lakkaa vastaamasta sinä hetkenä, kun työn VPN yhdistää. Joskus reittikomento korjaa sen sekunneissa; joskus sama reitti on oikein ja paketit silti katoavat, mikä tarkoittaa, että edessäsi on toinen ongelma, jolla on samankaltainen oire. Päätös tiivistyy kolmeen kysymykseen, ja niiden esittäminen väärässä järjestyksessä on syy siihen, miksi ihmiset viettävät koko illan reittejä poistellen ja uudelleen lisäillen.

Kolme kysymystä ennen mitään komentoa

Ensimmäinen: onko paikalliselle etuliitteelle merkintä, ja osoittaako se fyysiseen sovittimeen? Toinen: saako asiakas yhdyskäytävältä paikallisen verkon luvan tai kiellon yhdistäessään? Kolmas: tarvitsetko vain lähtevän yhteyden lähiverkkoon, vai pitääkö myös jotain internetissä olevaa päästä koneellasi pyörivään palveluun?

Ensimmäinen kysymys erottaa reititysvian suodatusviasta. Toinen kertoo, saako reittikorjaus ylipäätään toimia. Kolmas muuttaa korjausta: reitti korjaa lähtevän liikenteen, kun taas saavuttamaton saapuva palvelu on yleensä kuuntelijan sidonnan ja paluupolun ongelma, jonka reitti pahentaa.

Kysymys yksi: reitti, suodatin vai nimi

Lue taulukko ennen kuin lisäät siihen mitään. Liitännän indeksillä on väliä, koska jokainen alla oleva reittikomento on ankkuroitu siihen:

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

Suoraan kytketty aliverkko säilyttää yleensä linkin reitin myös tunnelin ollessa päällä, joten merkintä voi olla olemassa ja liikenne silti epäonnistua. Tämä yhdistelmä on reitityksen jälkeen toimivan suodattimen allekirjoitus, ja se on tapaus, jossa toinen, tarkempi reitti ei muuta yhtään mitään.

Testaa erikseen osoitteella ja nimellä. Jos ping 192.168.1.50 vastaa eikä net view 192.168.1.50 vastaa, reititystaulukko ei ollut koskaan ongelma: tunneli vaihtoi resolverin eikä paikallinen nimi enää ratkea. Reitin lisääminen sitä varten on hukattua työtä.

Kysymys kaksi: salliiko yhdyskäytävä paikallisen lähiverkon käytön?

Kaupallinen asiakas asentaa muutakin kuin reittejä. Se saa käytännön yhdistäessään, ja se käytäntö voi sisältää nimenomaisen paikallisen verkon luvan. Cisco IPsec -käyttöönotoissa ryhmäkäytäntö kantaa split-tunneling-asetuksen ja erillisen paikallisen lähiverkon käytön lipun; asiakkaan valintaruutu on pyyntö, jonka yhdyskäytävä voi hylätä. AnyConnectissa profiili ohjaa splitin sisällytys- ja poissulkuluetteloita ja samaa lupaa. Windows RRAS:ssa vastineet ovat profiilin oletusyhdyskäytävävalinta sekä palvelimen jakamat staattiset reitit.

Kun lippu on pois päältä, dokumentoitu käyttäytyminen on, että asiakas estää liikenteen suoraan kytkettyyn aliverkkoon, vaikka kelvollinen, tarkempi reitti olisi olemassa. Siksi myös reitit, jotka eivät ole asiakkaan omia, voivat kadota sekunteja lisäämisesi jälkeen: asiakas rakentaa uudelleen sen tilan, joka sen käskettiin rakentaa, eikä taistele sinua vastaan.

Asiakasloki kirjaa päätöksen yhdistämishetkellä, ja sen lukeminen on nopeampaa kuin mikään koneella tehtävä koe. Jos loki sanoo, että paikallinen käyttö on estetty, pysähdy: mikään komentorivikorjaus ei selviä siitä, ja jäljelle jäävät vain käytännön muutos, resurssiin pääsy tunnelin kautta tai asiakkaan sulkeminen virtuaalikoneeseen ja isäntäkoneen jättäminen paikalliseen verkkoon.

Kysymys kolme: kumpaa suuntaa tarvitset?

Lähtevä liikenne lähellä olevaan laitteeseen on reitityskysymys. Osoita lähiverkon etuliite paikalliseen yhdyskäytävään metrikalla, joka on tarpeeksi pieni voittaakseen tunnelin oletusreitin:

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

Toinen muoto kiinnittää yhden laitteen, mitä haluat, kun yksi osoite on koko vaatimus. netsh-vastine kirjaa saman päätöksen liitännän nimen, ei indeksin mukaan:

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

Reittikomennot epäonnistuvat Parametri on virheellinen -virheeseen, kun osoite ja peite eivät täsmää, esimerkiksi isäntäosoite /24-peitteellä. Käytä verkon osoitetta aliverkkoreitille ja isäntäpeitettä yksittäiselle isännälle.

Saapuva on erilaista. Saman koneen VNC- tai SSH-palvelin muuttuu saavuttamattomaksi, kun saapuvan yhteyden vastaukset lähtevät VPN-yhdyskäytävän kautta eivätkä koskaan palaa. Tarkista, mitä palvelu kuuntelee, ennen kuin kosket reitteihin:

netstat -ano | findstr :5900

Yhteen tiettyyn osoitteeseen sidottu kuuntelija ei vastaa toisella liitännällä. Sen sitominen kaikkiin liitäntöihin on tietoinen päätös, joka tehdään yhdessä sen verkon rajaaman palomuurisäännön kanssa, johon luotat. Vasta sen jälkeen reittikorjaus palauttaa paluupolun.

Tee pienin sopiva muutos

Toinen tavallinen siirto on poistaa valinta ”Käytä oletusyhdyskäytävää etäverkossa” IPv4:n lisäasetuksista. Se pitää internetyhteyden paikallisena, mutta tekee kaksi asiaa kerralla: VPN lakkaa olemasta oletuspolku, ja asiakas lakkaa vastaanottamasta reittejä etäverkkoon, mukaan lukien multicast. Poista valinta, ja etälähiverkko katoaa, ellei palvelin työnnä niitä tiettyjä etäetuliitteitä, joita jokainen asiakas tarvitsee.

Tämä epäsymmetria ratkaisee työn järjestyksen. Jos etäpuolen on pysyttävä täysin saavutettavana, työnnä etäaliverkot palvelimesta ja jätä paikallinen oletus rauhaan. Jos et voi muuttaa palvelinta, lisää pysyvä reitti etäetuliitteeseen sen osoitteen kautta, jonka tunneli antoi, ja tarkista route print:llä, että etuliite osoittaa VPN-liitäntään ja oletus osoittaa edelleen fyysiseen yhdyskäytävään.

Vahvista sitten, että korjaus kestää uudelleenyhdistämisen, koska ei-pysyvät reitit kuolevat sovittimen mukana, ja skripti, joka ajetaan jokaisen yhteyden jälkeen, on niille rehellinen paikka. Testaa yhtä paikallista laitetta ja yhtä etäresurssia samassa istunnossa, katkaise, yhdistä uudelleen ja testaa taas. Jos paikallinen laite epäonnistuu edelleen reitin näyttäessä oikealta, palaa kysymykseen kaksi: asiakas suodattaa, ja vastaus on käytännön muutos eikä toinen kilpaileva reitti.