Miksi Windows-VPN tappaa paikallisen tulostimen ja miten sen voi estää
Täystunnelin asiakas omistaa oletusreitin, joten tulostin ja NAS lakkaavat vastaamasta. Poista se reitti ja lisää sitten tarvitsemasi työetuliitteet takaisin.
Yhdistä VPN ja tulostin katoaa, NAS-jako ei enää aukea ja viereisen koneen etätyöpöytäistunto aikakatkaistaan. Mikään ei mennyt rikki. Asiakas lisäsi oletusreitin ja omistaa nyt jokaisen kohteen, jonka kannettava voi nimetä, myös kolmen metrin päässä olevat. Siinä koko mekanismi, ja sen kutsuminen VPN-viaksi on juuri se, mikä muuttaa yhden rivin korjauksen tukitapaukseksi.
Lue reittitaulukko ensin
Ennen kuin muutat mitään, ota IPv4-taulukko komennolla route print -4 ja säilytä tuloste. Yhdistä, ota uudelleen ja vertaa rivejä 0.0.0.0: aktiivinen oletusreitti nimeää liitännän, ja jos tämä liitäntä on tunneli, paikallinen tulostus ja selailu lähetetään ensin toimistoon.
Toisen sarakkeen liitännän numero on se, johon pysyvän reitin on myöhemmin viitattava, joten merkitse se muistiin, kun tunneli on päällä. Se on myös arvo, joka muuttuu, kun sovitin luodaan uudelleen, minkä vuoksi siihen kiinnitetyt reitit voivat hiljaa elää hyödyllisyytensä ohi.
Poista oletusreitti kolmella tavalla
Sisäänrakennetussa Windows-profiilissa säätö on valintaruutu. Avaa yhteyden ominaisuudet, IPv4, sitten Lisäasetukset, ja tyhjennä Use default gateway on remote network; uudempi Asetukset-sovellus kätkee saman valintaikkunan yhden kerroksen syvemmälle. Korotetusta komentokehotteesta sama muutos on yksi cmdlet:
Set-VpnConnection -Name "Corp" -SplitTunneling $true
OpenVPN-profiili toimii eri tavalla, minkä vuoksi sen käytös hämmentää niitä, jotka odottavat valintaruutua. Sen redirect-gateway def1-direktiivi ei korvaa oletusreittiä lainkaan; se asentaa kaksi puolivälin reittiä, 0.0.0.0/1 ja 128.0.0.0/1, jotka yhdessä voittavat oletusreitin sitä poistamatta. Koska alkuperäinen oletusreitti säilyy, kohtaan net_gateway osoittavan etuliitteen lisääminen lähettää vain sen etuliitteen takaisin paikalliseen reitittimeen. Tämä yksityiskohta selittää, miksi def1-profiilin korjaus on etuliitereitti eikä valintaruutu, jota kukaan ei löydä.
Lisää takaisin vain se, mikä kuuluu työhön
Kun oletusreitti on poissa, tunneli ei kuljeta mitään, joten työetuliitteet on nimettävä nimenomaisesti. Cmdlet, joka sitoo etuliitteen yhteyteen, on turvallisempi kuin pysyvä reitti, koska se asennetaan vain kyseisen yhteyden ollessa päällä eikä riipu liitännän numerosta:
Add-VpnConnectionRoute -ConnectionName "Corp" -DestinationPrefix 172.20.0.0/16
Vanhempi tapa toimii edelleen ja on edelleen jokaisessa tarkistuslistassa: route -p add 172.20.0.0 mask 255.255.0.0 172.20.0.1 if 14, tunnelin omalla liitäntäindeksillä ja yhdyskäytävän osoitteella. Se säilyy uudelleenkäynnistysten yli, mikä on tarkoitus ja myös vaara, koska indeksi voi seuraavassa käynnistyksessä kuulua jollekin muulle.
Loput ratkaisevat metriikat. Jos sekä fyysinen että tunnelisovitin vaativat reittiä samalle etuliitteelle, pienempi metriikka voittaa, ja tunnelin metriikan nostaminen on asiakaspuolen laillinen säätö eikä kikka.
Kun palvelin päättää puolestasi
Asiakas, joka jättää valintaruutusäätösi huomiotta, tottelee yleensä käytäntöä. Cisco-profiileissa on asetus Allow Local LAN Access, ja headend voi työntää tunnel-all-käytännön, joka ohittaa sen, mitä asiakas muuten haluaisi; pakollisessa tunnelissa ei ole paikallista kytkintä käännettäväksi. Lue asiakkaan loki työnnetyistä reiteistä ja käytäntöriveistä sen sijaan, että tarkistaisit saman valintaikkunan uudelleen.
Katso sitten nimien selvitystä, joka on reitityksestä erillinen kytkin. Jaettu tunneli voi yhä saada sisäisen resolverin ja hakuetuliitteen, joten paikallinen laite on tavoitettavissa osoitteella ja löytämätön nimellä, kunnes myös DNS-puoli on korjattu.
Päällekkäisyydet ovat eri ongelma
Jos kodin LAN ja toimiston LAN jakavat etuliitteen kuten 192.168.0.0/24, mikään reitti ei voi erottaa niitä. Jokaisella kyseisen alueen paketilla on yksi hakutulos, ja korjaus on numeroida toinen puoli uudelleen tai saavuttaa toimisto poolista käännetyn osoitteen kautta. Tarkempien reittien lisääminen vain siirtää sitä, kumpi verkon puoli hajoaa.
Lopeta yhteen tarkistukseen viiden sijaan: yhdistä ja aja sitten tracert sisäistä ja julkista isäntää vastaan. Ensimmäisen hypyn pitäisi erota, ja jos se ei eroa, jako ei ole paikallaan riippumatta siitä, mitä asiakas raportoi. Yhdistä sitten kerran uudelleen ja toista, koska työnnetyt reitit palaavat joka istunnolla.