Via dividita tunelo atingas la aplikaĵon sed ne ĝian DNS-servilon
Dividita tunelo povas enkursigi la subreton de la aplikaĵo kaj tamen forlasi la solvilon apud ĝi. Aldonu la gastigan itineron, poste kontrolu kiun servilon Windows efektive elektas.
Enkursigi la subreton de la aplikaĵo estas la evidenta parto de dividita tunelo, kaj ĝi ne estas la tuta laboro. La solvilo ofte sidas sur alia adreso ol la aplikaĵo, kiun ĝi servas, do funkcianta tunelo povas lasi la serĉadon ekster ĝi. Profilo, kiu portas 10.80.0.0/16 kaj nenion alian, sendas la demandon pri 10.90.0.53 tra la loka interfaco, kie neniu privata zono ekzistas. Aldonu la itineron al la solvilo, poste rigardu la duan duonon de la problemo: kiun servilon la kliento efektive elektas.
La mito: unu itinero kovras la tutan servon
Dividita tunelo estas listo de celoj, kiuj iras tra la konekto, ne priskribo de servo. La subreto de la aplikaĵo kaj la adreso de la solvilo estas du celoj, kaj profilo povas porti unu sen la alia. Kiam tio okazas, la aplikaĵo estas atingebla laŭ adreso dum ĝia nomo malsukcesas, kio aspektas kiel DNS-misŝalto prefere ol kiel itinera breĉo.
Ankaŭ la subreto ĉirkaŭ la solvilo ne estas aŭtomate kovrita. Gastiga itinero al unu adreso sufiĉas por tiu solvilo kaj ne malfermas ĝiajn najbarojn. Tio estas la senco de gastiga itinero: mallarĝa laŭ koncepto, kaj facile forgesebla kiam la sekva servo aperas en la sama subreto.
Tri aferoj devas validi por ke la serĉado funkciu: la kliento enkursigas la adreson de la solvilo tra la tunelo, la pordego akceptas kaj plusendas tiun peton, kaj la solvilo akceptas la fonton, kiun ĝi ricevas. Ankaŭ responso devas reveni laŭ la interkonsentita vojo. Se mankas iu el ili, la simptomo estas identa, tial indas skribi la adresan tabelon antaŭ ol tuŝi agordon.
Determinu, kiujn adresojn la profilo devas porti
Listigu la celojn laŭ ordo: la reto de la aplikaĵo, la adreso de la solvilo kaj la publika finpunkto, kiu finas la tunelon mem. La tria neniam rajtas esti enkursigita en la tunelon, ĉar la ekstera konekto bezonas vojon, kiu ekzistas antaŭ la tunelo.
| Destination | Coverage this example needs |
|---|---|
| Application network | 10.80.0.0/16 through the VPN |
| Private resolver | 10.90.0.53/32 through the VPN |
| Public VPN endpoint | Normal internet path, outside the tunnel |
Inkluzivu kaj UDP kaj TCP por DNS, ĉar de efektivigoj oni atendas subtenon de TCP apud UDP, kaj blokita TCP-vojo produktas malrapidajn, partajn malsukcesojn anstataŭ purajn. Se la privata zono estas servata ankaŭ per IPv6, la ekvivalenta gastiga escepto uzas IPv6-adreson kaj prefikson kaj estas aparta ero.
Notu, kion la profilo jam kovras antaŭ ol aldoni ion. Duobla itinero estas sendanĝera, sed neatendita ekzistanta itinero diras al vi, ke la profilo estis desegnita por alia adresa plano ol tiu, kiun vi ricevis.
Aldonu la gastigan itineron per la posedanto de la konekto
Por loke administrata denaska Windows-profilo, la itinero apartenas al la konekto prefere ol al la tutmonda enkursiga tabelo de la maŝino. Antaŭrigardu la aldonon unue, poste apliku ĝin kun la sama amplekso, kiun la profilo uzas.
Add-VpnConnectionRoute -ConnectionName 'Office VPN' -DestinationPrefix '10.90.0.53/32' -WhatIf Get-VpnConnection -Name 'Office VPN' | Select-Object -ExpandProperty Routes
La unua komando antaŭrigardas la ŝanĝon sen instali ion ajn, kaj la dua listigas la itinerojn, kiujn la profilo nun portas. La referenco de Add-VpnConnectionRoute de Microsoft dokumentas la ampleksojn por unuopa uzanto kaj por ĉiuj uzantoj; profilo por ĉiuj uzantoj bezonas sian propran ampleksan parametron, kaj komando por unuopa uzanto kontraŭ profilo por ĉiuj uzantoj malsukcesas aŭ finiĝas en la malĝusta loko.
Kiam la profilo estas administrata aŭ venas de vendista kliento, la ŝanĝo apartenas al tiu posedanto. Staki permanentan sistemitinon sur konektan politikon funkcias ĝis la politiko estos reaplikata kaj la itinero malaperos, kio kutime okazas dum subtena alvoko prefere ol dum testado. Tiu malsukceso estas silenta: la itinero malaperas, la nomo ĉesas solviĝi, kaj neniu ligas la du eventojn. Metu la ŝanĝon en la propran rikordon de la posedanto, por ke la sekva reaplikado portu ĝin anstataŭ forviŝi ĝin.
Post aplikado, rekonektu la profilon anstataŭ supozi, ke la itinero ekvalidis. Itineraj ŝanĝoj sur viva konekto ne ĉiam estas kaptataj, kaj rekonekto ankaŭ reproduktas la staton, kiun viaj uzantoj efektive havos.
Kontrolu, kiun solvilon la kliento efektive uzis
Itinero regas pakaĵojn adresitajn al la solvilo. Ĝi ne decidas, kiuj nomoj estu senditaj tien, kaj tiu elekto estas aparta mekanismo. En Windows, efektivaj nomspacaj reguloj povas elekti solvilon por ĉiu domajno, dum la DNS-agordoj de la profilo liveras defaŭlton. Tiuj du tavoloj povas malkonsenti sen produkti ajnan eraron, tial rekta demando estas nur duono de la pruvo.
Get-DnsClientNrptPolicy Resolve-DnsName app.svc.example -Server 10.90.0.53 -Type A
La unua komando presas la validan nomspacan politikon, kaj la dua demandas la privatan solvilon rekte pri la nomo de la aplikaĵo. Rekta respondo pruvas, ke la vojo kaj la solvilo funkcias; ĝi ne pruvas, ke la propra serĉado de la aplikaĵo elektis tiun servilon. Komparu ĝin kun normala serĉado de la sama nomo kaj kun la respondo, kiun la aplikaĵo ricevas.
Konsideru kaŝmemorojn kaj sekuran DNS ĉe la retumila nivelo, kiu povas tute preterpasi la sisteman solvilon por nomoj, kiujn uzanto tajpis. Serĉa sufikso estas alia falsa spuro: ĝi etendas mallongan nomon al plene kvalifikita kaj havas nenion komunan kun tio, kiu servilo respondas.
Finu per rekonekto kaj ripeto de la normala serĉado, poste konfirmu, ke ordinara retumado ankoraŭ sekvas sian aprobitan politikon. Anstataŭigi la privatan solvilon per publika por solvi nerilatan nomon ne estas riparo, kaj ĝi silente movas privatajn demandojn tien, kien ili neniam estis celitaj.