VPN bloķē lokālo LAN sistēmā Windows: maršruts vai klienta politika?

Printeris, NAS vai izstrādes mašīna uz jūsu paša galda pārstāj atbildēt tajā mirklī, kad pieslēdzas darba VPN. Dažkārt viena maršruta komanda to salabo sekundēs; dažkārt tas pats maršruts ir pareizs un paketes tomēr pazūd, kas nozīmē, ka redzat citu problēmu ar līdzīgu simptomu. Lēmums reducējas uz trim jautājumiem, un to uzdošana nepareizā secībā ir iemesls, kāpēc cilvēki pavada visu vakaru, dzēšot un atkal pievienojot maršrutus.

Trīs jautājumi pirms jebkuras komandas

Pirmkārt: vai lokālajam prefiksam ir ieraksts, un vai tas norāda uz fizisko adapteri? Otrkārt: vai klientam pieslēgšanās laikā no vārtejas tiek piešķirta atļauja vai atteikums lokālajam tīklam? Treškārt: vai jums vajadzīga tikai izejošā piekļuve LAN, vai arī kaut kam internetā jāsasniedz pakalpojums, kas darbojas jūsu mašīnā?

Pirmais jautājums atdala maršrutēšanas kļūmi no filtrēšanas kļūmes. Otrais pasaka, vai maršruta labojumam vispār ir atļauts darboties. Trešais maina labojumu: maršruts labo izejošo datplūsmu, bet nesasniedzams ienākošais pakalpojums parasti ir klausītāja piesaistes un atgriešanās ceļa problēma, ko maršruts padara sliktāku.

Jautājums pirmais: maršruts, filtrs vai nosaukums

Izlasiet tabulu, pirms kaut ko tai pievienojat. Saskarnes indeksam ir nozīme, jo katra maršruta komanda zemāk ir piesaistīta tam:

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

Tieši pievienots apakštīkls parasti saglabā on-link maršrutu arī tad, kad tunelis ir aktīvs, tāpēc ieraksts var pastāvēt un datplūsma tomēr var neizdoties. Šī kombinācija ir pēc maršrutēšanas darbojoša filtra paraksts, un tas ir gadījums, kad otrs, precīzāks maršruts nemaina pilnīgi neko.

Pārbaudiet atsevišķi pēc adreses un pēc nosaukuma. Ja ping 192.168.1.50 atbild un net view 192.168.1.50 neatbild, maršrutu tabula nekad nav bijusi problēma: tunelis nomainīja risinātāju, un lokālais nosaukums vairs netiek atrisināts. Maršruta pievienošana tam ir veltīgs darbs.

Jautājums otrais: vai vārteja atļauj piekļuvi lokālajam LAN?

Komerciāls klients instalē vairāk nekā maršrutus. Tas pieslēgšanās laikā saņem politiku, un šī politika var ietvert skaidru lokālā tīkla atļauju. Cisco IPsec izvietojumos grupas politika nes split-tunneling iestatījumu un atsevišķu lokālā LAN piekļuves karodziņu; klienta izvēles rūtiņa ir pieprasījums, ko vārteja var atteikt. AnyConnect gadījumā profils kontrolē split iekļaušanas un izslēgšanas sarakstus un to pašu atļauju. Windows RRAS atbilstošie ir profila noklusējuma vārtejas opcija un servera piešķirtie statiskie maršruti.

Kad karodziņš ir izslēgts, dokumentētā uzvedība ir tāda, ka klients bloķē datplūsmu uz tieši pievienoto apakštīklu, lai gan pastāv derīgs, precīzāks maršruts. Tāpēc arī maršruti, kas klientam nepieder, var pazust dažas sekundes pēc pievienošanas: klients no jauna būvē stāvokli, ko tam lika būvēt, nevis cīnās ar jums.

Klienta žurnāls pieslēgšanās laikā reģistrē lēmumu, un tā lasīšana ir ātrāka par jebkuru eksperimentu mašīnā. Ja žurnāls saka, ka lokālā piekļuve ir bloķēta, apstājieties: neviens komandrindas labojums to nepārspēs, un paliek tikai politikas maiņa, resursa sasniegšana caur tuneli, vai klienta ievietošana virtuālajā mašīnā un saimnieka atstāšana lokālajā tīklā.

Jautājums trešais: kāds virziens jums ir vajadzīgs?

Izejošā datplūsma uz tuvējo ierīci ir maršrutēšanas jautājums. Novirziet LAN prefiksu uz vietējo vārteju ar metrisko vērtību, kas ir pietiekami zema, lai pārspētu tuneļa noklusējuma maršrutu:

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

Otrā forma pievieno vienu ierīci, un to jūs vēlaties, kad viena adrese ir visa prasība. netsh ekvivalents reģistrē to pašu lēmumu pēc saskarnes nosaukuma, nevis indeksa:

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

Maršruta komandas neizdodas ar Parametrs ir nepareizs, kad adrese un maska nesakrīt, piemēram, saimnieka adrese ar /24 masku. Apakštīkla maršrutam izmantojiet tīkla adresi, bet vienam saimniekam — saimnieka masku.

Ienākošā ir citāda. VNC vai SSH serveris tajā pašā mašīnā kļūst nesasniedzams, kad atbildes uz ienākošo savienojumu iziet caur VPN vārteju un nekad neatgriežas. Pirms pieskaraties maršrutiem, pārbaudiet, uz ko pakalpojums klausās:

netstat -ano | findstr :5900

Klausītājs, kas piesaistīts vienai konkrētai adresei, neatbildēs otrā saskarnē. Tā piesaiste visām saskarnēm ir apzināts lēmums, pieņemts kopā ar ugunsmūra noteikumu, kas ierobežots uz tīklu, kuram uzticaties. Tikai pēc tam maršruta labojums atjauno atgriešanās ceļu.

Izmantojiet mazāko atbilstošo izmaiņu

Otrs izplatītais solis ir noņemt atzīmi “Izmantot noklusējuma vārteju attālajā tīklā” IPv4 papildu rekvizītos. Tas saglabā interneta datplūsmu lokālu, bet dara divas lietas reizē: VPN pārstāj būt noklusējuma ceļš, un klients pārstāj saņemt maršrutus attālajam tīklam, tostarp multicast. Noņemiet atzīmi, un attālais LAN pazūd, ja vien serveris neiedzen konkrētos attālos prefiksus, kas vajadzīgi katram klientam.

Šī asimetrija nosaka darba secību. Ja attālajai pusei jāpaliek pilnībā sasniedzamai, iedzeniet attālos apakštīklus no servera un atstājiet lokālo noklusējumu mierā. Ja nevarat mainīt serveri, pievienojiet pastāvīgu maršrutu uz attālo prefiksu caur adresi, ko piešķīra tunelis, un pārbaudiet ar route print, vai prefikss norāda uz VPN saskarni, kamēr noklusējums joprojām norāda uz fizisko vārteju.

Pēc tam apstipriniet, ka labojums pārdzīvo atkārtotu savienojumu, jo nepastāvīgie maršruti mirst kopā ar adapteri, un skripts, kas darbojas pēc katra savienojuma, ir godīgā vieta tiem. Tajā pašā sesijā pārbaudiet vienu lokālu ierīci un vienu attālu resursu, atvienojieties, pievienojieties vēlreiz un pārbaudiet vēlreiz. Ja lokālā ierīce joprojām neizdodas, kamēr maršruts izskatās pareizs, atgriezieties pie otrā jautājuma: klients filtrē, un atbilde ir politikas maiņa, nevis otrs konkurējošs maršruts.