VPN blokas lokan LAN en Windows: ĉu vojo aŭ klienta politiko?

Presilo, NAS aŭ evoluiga maŝino sur via propra skribotablo ĉesas respondi en la momento, kiam la labora VPN konektiĝas. Foje voja ordono riparas tion en sekundoj; foje la sama vojo estas ĝusta kaj la pakaĵoj tamen malaperas, kio signifas, ke vi rigardas alian problemon kun simila simptomo. La decido reduktiĝas al tri demandoj, kaj meti ilin en la malĝustan ordon estas kial homoj pasigas tutan vesperon forigante kaj re-aldonante vojojn.

Tri demandoj antaŭ ajna ordono

Unue: ĉu ekzistas ero por la loka prefikso, kaj ĉu ĝi montras al la fizika adaptilo? Due: ĉu la kliento ricevas permeson aŭ rifuzon de loka reto de la pordo ĉe konekto? Trie: ĉu vi bezonas nur eliran aliron al la LAN, aŭ ĉu io en la interreto ankaŭ devas atingi servon kurantan sur via maŝino?

La unua demando apartigas vojigan difekton de filtra difekto. La dua diras, ĉu voja ripeto entute rajtas funkcii. La tria ŝanĝas la riparon: vojo riparas eliran trafikon, dum neatingebla enira servo kutime estas problemo de bindado de aŭskultanto kaj de reira vojo, kiun vojo plimalbonigas.

Demando unu: vojo, filtrilo aŭ nomo

Legi la tabelon antaŭ ol aldoni ion al ĝi. La interfaca indekso gravas, ĉar ĉiu voja ordono sube estas ankrita al ĝi:

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

Rekte konektita subretaro kutime konservas surlokan vojon eĉ dum la tunelo estas aktiva, do ero povas ekzisti kaj la trafiko tamen malsukcesi. Tiu kombinaĵo estas la subskribo de filtrilo, kiu funkcias post vojigo, kaj ĝi estas la kazo, kie dua, pli specifa vojo ŝanĝas absolute nenion.

Testu aparte laŭ adreso kaj laŭ nomo. Se ping 192.168.1.50 respondas kaj net view 192.168.1.50 ne, la vojiga tabelo neniam estis la problemo: la tunelo ŝanĝis la solvilon kaj la loka nomo ne plu solviĝas. Aldoni vojon por tio estas perdita laboro.

Demando du: ĉu la pordo permesas lokan LAN-aliron?

Komerca kliento instalas pli ol vojojn. Ĝi ricevas politikon ĉe konekto, kaj tiu politiko povas inkluzivi eksplicitan permeson de loka reto. En Cisco IPsec-eksplicaĵoj la grupa politiko portas la agordon de split-tunneling kaj apartan flagon de loka LAN-aliro; la markobutono en la kliento estas peto, kiun la pordo povas rifuzi. En AnyConnect la profilo regas la listojn de inkluzivo kaj ekskluzivo de split kaj la saman permeson. Sur Windows RRAS la ekvivalentoj estas la opcio de defaŭlta pordo en la profilo plus la statikaj vojoj, kiujn la servilo atribuas.

Kiam la flago estas malŝaltita, la dokumentita konduto estas, ke la kliento blokas trafikon al la rekte konektita subretaro eĉ se validas pli specifa vojo. Tial ankaŭ vojoj, kiujn la kliento ne posedas, povas malaperi sekundojn post kiam vi aldonis ilin: la kliento rekonstruas la staton, kiun oni ordonis al ĝi konstrui, ne luktas kontraŭ vi.

La klienta protokolo registras la decidon ĉe konekto, kaj legi ĝin estas pli rapide ol ajna eksperimento sur la maŝino. Se la protokolo diras, ke loka aliro estas blokita, haltu: neniu komandlinia ripeto postvivas tion, kaj la solaj restantaj vojoj estas politika ŝanĝo, atingi la rimedon per la tunelo, aŭ enfermi la klienton en virtuala maŝino kaj lasi la gastiganton sur la loka reto.

Demando tri: kiun direkton vi bezonas?

Elira trafiko al proksima aparato estas vojiga demando. Direktu la LAN-prefikson al la loka pordo kun metriko sufiĉe malalta por venki la defaŭltan vojon de la tunelo:

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

La dua formo fiksas unu aparaton, kio estas tio, kion vi volas, kiam unu adreso estas la tuta postulo. La netsh-ekvivalento registras la saman decidon laŭ interfaca nomo anstataŭ indekso:

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

Vojaj ordonoj malsukcesas kun La parametro estas malĝusta, kiam la adreso kaj la masko ne kongruas, ekzemple gastiga adreso kun /24-masko. Uzu la retan adreson por subretara vojo kaj gastigan maskon por unu gastiganto.

Enira estas malsama. VNC- aŭ SSH-servilo sur la sama maŝino fariĝas neatingebla, kiam respondoj al enira konekto forlasas tra la VPN-pordo kaj neniam revenas. Kontrolu, al kio la servo aŭskultas antaŭ ol tuŝi vojojn:

netstat -ano | findstr :5900

Aŭskultanto bindita al unu specifa adreso ne respondos sur la alia interfaco. Bindi ĝin al ĉiuj interfacoj estas konscia decido, farita kune kun fajroŝirma regulo limigita al la reto, kiun vi fidas. Nur post tio la voja ripeto restarigas la reiran vojon.

Apliku la plej malgrandan ŝanĝon, kiu kongruas

La alia kutima movo estas malmarki “Uzi defaŭltan pordon en fora reto” en la altnivelaj ecoj de IPv4. Ĝi tenas interretan trafikon loka, sed faras du aferojn samtempe: la VPN ĉesas esti la defaŭlta vojo, kaj la kliento ĉesas ricevi vojojn por la fora reto, inkluzive de multicast. Malmarku ĝin kaj la fora LAN malaperas, se la servilo ne puŝas la specifajn forajn prefiksojn, kiujn ĉiu kliento bezonas.

Tiu nesimetrio decidas la laboran ordon. Se la fora flanko devas resti plene atingebla, puŝu forajn subretarojn de la servilo kaj lasu la lokan defaŭlton trankvila. Se vi ne povas ŝanĝi la servilon, aldonu permanentan vojon al la fora prefikso tra la adreso, kiun la tunelo atribuis, kaj kontrolu per route print, ke la prefikso montras al la VPN-interfaco dum la defaŭlto ankoraŭ montras al la fizika pordo.

Poste konfirmu, ke la ripeto postvivas rekonekton, ĉar nepermanentaj vojoj mortas kun la adaptilo, kaj skripto, kiu ruliĝas post ĉiu konekto, estas la honesta loko por ili. Testu unu lokan aparaton kaj unu foran rimedon en la sama seanco, malkonektu, rekonektu, kaj testu denove. Se la loka aparato ankoraŭ malsukcesas dum la vojo aspektas ĝusta, reiru al demando du: la kliento filtras, kaj la respondo estas politika ŝanĝo anstataŭ dua konkurenca vojo.