VPN bllokon LAN-in lokal në Windows: rrugë apo politikë e klientit?

Një printer, një NAS ose një makinë zhvillimi në tavolinën tuaj ndalojnë së përgjigjuri në momentin kur lidhet VPN-i i punës. Ndonjëherë një komandë rrugë e rregullon në sekonda; ndonjëherë e njëjta rrugë është e saktë dhe paketat prapë zhduken, që do të thotë se po shikoni një problem tjetër me një simptomë të ngjashme. Vendimi zbret në tre pyetje, dhe t'i bësh ato në rendin e gabuar është arsyeja pse njerëzit kalojnë një mbrëmje të tërë duke fshirë dhe duke shtuar përsëri rrugë.

Tre pyetje përpara çdo komande

Së pari: a ka një hyrje për prefiksin lokal, dhe a tregon ajo për adaptorin fizik? Së dyti: a merr klienti një leje ose një refuzim për rrjetin lokal nga porta gjatë lidhjes? Së treti: a ju duhet vetëm akses dalës në LAN, apo diçka në internet duhet gjithashtu të arrijë një shërbim që punon në makinën tuaj?

Pyetja e parë ndan një defekt rrugëtimi nga një defekt filtrimi. E dyta thotë nëse një rregullim rrugë lejohet të punojë fare. E treta ndryshon riparimin: një rrugë rregullon trafikun dalës, ndërsa një shërbim hyrës i paarritshëm është zakonisht një problem i lidhjes së dëgjuesit dhe i rrugës së kthimit që një rrugë e përkeqëson.

Pyetja një: rrugë, filtër apo emër

Lexoni tabelën përpara se t'i shtoni diçka. Indeksi i ndërfaqes ka rëndësi, sepse çdo komandë rrugë më poshtë është e ankoruar në të:

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

Një nënrrjet i lidhur drejtpërdrejt zakonisht mban një rrugë on-link edhe kur tuneli është aktiv, kështu që një hyrje mund të ekzistojë dhe trafiku prapë mund të dështojë. Ky kombinim është firma e një filtri që punon pas rrugëtimit, dhe ky është rasti kur një rrugë e dytë, më specifike, nuk ndryshon absolutisht asgjë.

Testoni veçmas sipas adresës dhe sipas emrit. Nëse ping 192.168.1.50 përgjigjet dhe net view 192.168.1.50 jo, tabela e rrugëtimit nuk ishte kurrë problemi: tuneli ndryshoi zgjidhësin dhe emri lokal nuk zgjidhet më. Shtimi i një rrugë për këtë është punë e humbur.

Pyetja dy: a lejon porta aksesin në LAN-in lokal?

Një klient komercial instalon më shumë se rrugë. Ai merr një politikë gjatë lidhjes, dhe ajo politikë mund të përfshijë një leje të shprehur për rrjetin lokal. Në vendosjet Cisco IPsec politika e grupit mban cilësimin e split-tunneling dhe një flamur të veçantë për aksesin në LAN-in lokal; kutia e zgjedhjes në klient është një kërkesë që porta mund ta refuzojë. Në AnyConnect profili kontrollon listat e përfshirjes dhe përjashtimit të split dhe të njëjtën leje. Në Windows RRAS ekuivalentët janë opsioni i portës së paracaktuar në profil plus rrugët statike që cakton serveri.

Kur flamuri është i fikur, sjellja e dokumentuar është që klienti bllokon trafikun drejt nënrrjetit të lidhur drejtpërdrejt, edhe pse ekziston një rrugë e vlefshme, më specifike. Kjo është edhe arsyeja pse rrugët që klienti nuk i zotëron mund të zhduken sekonda pasi t'i shtoni: klienti po rindërton gjendjen që i është thënë të ndërtojë, nuk po lufton kundër jush.

Regjistri i klientit shënon vendimin gjatë lidhjes, dhe leximi i tij është më i shpejtë se çdo eksperiment në makinë. Nëse regjistri thotë se aksesi lokal është i bllokuar, ndaloni: asnjë rregullim i rreshtit të komandës nuk i mbijeton kësaj, dhe rrugët e vetme që mbeten janë një ndryshim politike, arritja e burimit përmes tunelit, ose mbyllja e klientit në një makinë virtuale dhe lënia e hostit në rrjetin lokal.

Pyetja tre: cili drejtim ju nevojitet?

Trafiku dalës drejt një pajisjeje të afërt është një çështje rrugëtimi. Drejtoni prefiksin e LAN-it drejt portës lokale me një metrikë mjaft të ulët për të mundur rrugën e paracaktuar të tunelit:

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

Forma e dytë fikson një pajisje të vetme, dhe kjo është ajo që dëshironi kur një adresë është e gjithë kërkesa. Ekuivalenti netsh regjistron të njëjtin vendim sipas emrit të ndërfaqes dhe jo sipas indeksit:

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

Komandat e rrugës dështojnë me Parametri është i gabuar kur adresa dhe maska nuk përputhen, për shembull një adresë hosti me maskë /24. Për një rrugë nënrrjeti përdorni adresën e rrjetit, dhe për një host të vetëm maskën e hostit.

Trafiku hyrës është i ndryshëm. Një server VNC ose SSH në të njëjtën makinë bëhet i paarritshëm kur përgjigjet ndaj një lidhjeje hyrëse dalin përmes portës VPN dhe nuk kthehen kurrë. Kontrolloni në çfarë dëgjon shërbimi përpara se të prekni rrugët:

netstat -ano | findstr :5900

Një dëgjues i lidhur me një adresë të caktuar nuk do të përgjigjet në ndërfaqen tjetër. Lidhja e tij me të gjitha ndërfaqet është një vendim i qëllimshëm, marrë së bashku me një rregull muri zjarri të kufizuar në rrjetin që i besoni. Vetëm pas kësaj riparimi i rrugës riktheu rrugën e kthimit.

Zbatoni ndryshimin më të vogël që përshtatet

Lëvizja tjetër e zakonshme është heqja e shenjës te «Përdor portën e paracaktuar në rrjetin e largët» në vetitë e avancuara të IPv4. Kjo mban trafikun e internetit lokal, por bën dy gjëra njëherësh: VPN-i nuk është më rruga e paracaktuar, dhe klienti nuk merr më rrugë për rrjetin e largët, përfshirë multicast. Hiqni shenjën dhe LAN-i i largët zhduket, përveç nëse serveri shtyn prefikset e largëta specifike që i nevojiten çdo klienti.

Kjo asimetri vendos rendin e punës. Nëse ana e largët duhet të mbetet plotësisht e arritshme, shtyni nënrrjetet e largëta nga serveri dhe lini të paracaktuarën lokale të qetë. Nëse nuk mund të ndryshoni serverin, shtoni një rrugë të përhershme drejt prefiksit të largët përmes adresës që caktoi tuneli, dhe kontrolloni me route print se prefiksi tregon ndërfaqen VPN ndërsa e paracaktuara vazhdon të tregojë portën fizike.

Më pas konfirmoni se riparimi i mbijeton një rilidhjeje, sepse rrugët jo të përhershme vdesin me adaptorin dhe një skript që ekzekutohet pas çdo lidhjeje është vendi i ndershëm për to. Testoni një pajisje lokale dhe një burim të largët në të njëjtën sesion, shkëputuni, rilidhuni dhe testoni përsëri. Nëse pajisja lokale vazhdon të dështojë ndërsa rruga duket e saktë, kthehuni te pyetja dy: klienti po filtron, dhe përgjigja është një ndryshim politike dhe jo një rrugë e dytë konkurruese.