Vaš razdeljeni tunel doseže aplikacijo, ne pa njenega strežnika DNS
Razdeljeni tunel lahko usmerja podomrežje aplikacije in vseeno spusti razreševalnik ob njem. Dodajte pot do gostitelja in nato preverite, kateri strežnik Windows v resnici izbere.
Usmerjanje podomrežja aplikacije je očiten del razdeljenega tunela in to ni vse delo. Razreševalnik pogosto sedi na drugem naslovu kot aplikacija, ki ji služi, zato lahko delujoč tunel iskanje vseeno pusti zunaj njega. Profil, ki nosi 10.80.0.0/16 in nič drugega, pošlje poizvedbo za 10.90.0.53 skozi lokalni vmesnik, kjer ne obstaja nobena zasebna cona. Dodajte pot do razreševalnika in nato poglejte drugo polovico težave: kateri strežnik odjemalec v resnici izbere.
Mit: ena pot pokrije celotno storitev
Razdeljeni tunel je seznam ciljev, ki gredo skozi povezavo, ne opis storitve. Podomrežje aplikacije in naslov razreševalnika sta dva cilja in profil lahko nosi enega brez drugega. Ko se to zgodi, je aplikacija dosegljiva po naslovu, medtem ko njeno ime ne uspe, kar je videti kot okvara DNS in ne kot vrzel v usmerjanju.
Tudi podomrežje okoli razreševalnika ni samodejno pokrito. Pot do gostitelja na en naslov zadostuje za ta razreševalnik in ne odpre njegovih sosedov. To je smisel poti do gostitelja: po zasnovi ozka in lahko jo pozabimo, ko se naslednja storitev pojavi v istem podomrežju.
Da iskanje deluje, morajo veljati tri stvari: odjemalec usmerja naslov razreševalnika skozi tunel, prehod zahtevo sprejme in posreduje, razreševalnik pa sprejme vir, ki ga prejme. Tudi odgovor se mora vrniti po dogovorjeni poti. Če manjka katera koli, je simptom enak, zato je vredno zapisati tabelo naslovov, preden se dotaknete konfiguracije.
Ugotovite, katere naslove mora profil nositi
Naštejte cilje po vrsti: omrežje aplikacije, naslov razreševalnika in javno končno točko, ki zaključi sam tunel. Tretjega nikoli ne smete usmeriti v tunel, ker zunanja povezava potrebuje pot, ki obstaja pred tunelom.
| 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 |
Vključite UDP in TCP za DNS, saj se od izvedb pričakuje podpora TCP poleg UDP, blokirana pot TCP pa povzroči počasne, delne napake namesto čistih. Če se zasebna cona streže tudi prek IPv6, enakovredna izjema za gostitelja uporablja naslov in predpono IPv6 in je ločen vnos.
Preden kar koli dodate, zapišite, kaj profil že pokriva. Podvojena pot je neškodljiva, a nepričakovana obstoječa pot pove, da je bil profil zasnovan za drugačen načrt naslovov od tistega, ki ste ga prejeli.
Dodajte pot do gostitelja prek lastnika povezave
Pri lokalno upravljanem izvornem profilu Windows pot pripada povezavi in ne globalni usmerjevalni tabeli stroja. Najprej si dodatek oglejte v predogledu, nato pa ga uporabite z enakim obsegom, kot ga uporablja profil.
Add-VpnConnectionRoute -ConnectionName 'Office VPN' -DestinationPrefix '10.90.0.53/32' -WhatIf Get-VpnConnection -Name 'Office VPN' | Select-Object -ExpandProperty Routes
Prvi ukaz prikaže spremembo v predogledu, ne da bi karkoli namestil, drugi pa našteje poti, ki jih profil trenutno nosi. Microsoftova referenca za Add-VpnConnectionRoute dokumentira obsega za posameznega uporabnika in za vse uporabnike; profil za vse uporabnike potrebuje svoj parameter obsega, ukaz za posameznega uporabnika proti profilu za vse uporabnike pa ne uspe ali konča na napačnem mestu.
Ko je profil upravljan ali prihaja iz odjemalca ponudnika, sprememba pripada temu lastniku. Zlaganje trajne sistemske poti na politiko povezave deluje, dokler politika ni znova uporabljena in pot ne izgine, kar se običajno zgodi med klicem podpore in ne med testiranjem. Ta okvara je tiha: pot izgine, ime se preneha razreševati in nihče ne poveže obeh dogodkov. Spremembo vnesite v lastnikov lastni zapis, da jo naslednja ponovna uporaba nosi, namesto da bi jo izbrisala.
Po uporabi profil znova povežite, namesto da bi domnevali, da je pot začela veljati. Spremembe poti na živi povezavi niso vedno zajete, ponovna povezava pa tudi poustvari stanje, ki ga bodo vaši uporabniki v resnici imeli.
Preverite, kateri razreševalnik je odjemalec v resnici uporabil
Pot nadzoruje pakete, naslovljene na razreševalnik. Ne odloča, katera imena je treba poslati tja, in ta izbira je ločen mehanizem. V Windows lahko veljavna pravila imenskega prostora izberejo razreševalnik za vsako domeno, medtem ko nastavitve DNS profila dajo privzeto vrednost. Ti dve plasti se lahko razhajata, ne da bi ustvarili kakršno koli napako, zato je neposredna poizvedba le polovica dokaza.
Get-DnsClientNrptPolicy Resolve-DnsName app.svc.example -Server 10.90.0.53 -Type A
Prvi ukaz izpiše veljavno politiko imenskega prostora, drugi pa zasebni razreševalnik neposredno vpraša za ime aplikacije. Neposreden odgovor dokazuje, da pot in razreševalnik delujeta; ne dokazuje, da je lastno iskanje aplikacije izbralo ta strežnik. Primerjajte ga z običajnim iskanjem istega imena in z odgovorom, ki ga prejme aplikacija.
Upoštevajte predpomnilnike in varni DNS na ravni brskalnika, ki lahko popolnoma obide sistemski razreševalnik za imena, ki jih je vnesel uporabnik. Iskalna pripona je še ena lažna sled: razširi kratko ime v popolnoma kvalificirano in nima nobene zveze s tem, kateri strežnik odgovori.
Končajte s ponovno povezavo in ponovitvijo običajnega iskanja, nato potrdite, da običajno brskanje še vedno sledi svoji odobreni politiki. Zamenjava zasebnega razreševalnika z javnim, da bi se razrešilo nepovezano ime, ni popravek in tiho premakne zasebne poizvedbe tja, kamor nikoli ne bi smele priti.