Jūsu sadalītais tunelis sasniedz lietotni, bet ne tās DNS serveri
Sadalītais tunelis var maršrutēt lietotnes apakštīklu un tomēr nomest blakus esošo risinātāju. Pievienojiet hosta maršrutu un pēc tam pārbaudiet, kuru serveri Windows faktiski izvēlas.
Lietotnes apakštīkla maršrutēšana ir sadalītā tuneļa acīmredzamā daļa, un tas nav viss darbs. Risinātājs bieži atrodas citā adresē nekā lietotne, kurai tas kalpo, tāpēc strādājošs tunelis joprojām var atstāt meklēšanu ārpus tā. Profils, kas satur 10.80.0.0/16 un neko citu, sūta 10.90.0.53 vaicājumu pa vietējo saskarni, kur privātas zonas nav. Pievienojiet risinātāja ceļu, pēc tam apskatiet problēmas otro pusi: kuru serveri klients faktiski izvēlas.
Mīts: viens maršruts aptver visu pakalpojumu
Sadalītais tunelis ir galamērķu saraksts, kas iet caur savienojumu, nevis pakalpojuma apraksts. Lietotnes apakštīkls un risinātāja adrese ir divi galamērķi, un profils var saturēt vienu bez otra. Kad tā notiek, lietotne ir sasniedzama pēc adreses, kamēr tās nosaukums neizdodas, kas izskatās kā DNS kļūda, nevis maršrutēšanas plaisa.
Apakštīkls ap risinātāju arī nav automātiski pārklāts. Hosta maršruts uz vienu adresi ir pietiekams šim risinātājam un neatver tā kaimiņus. Tāda ir hosta maršruta jēga: pēc nodoma šaurs un viegli aizmirstams, kad nākamais pakalpojums parādās tajā pašā apakštīklā.
Lai meklēšana darbotos, jāpastāv trim lietām: klients maršrutē risinātāja adresi caur tuneli, vārteja pieņem un pārsūta šo pieprasījumu, un risinātājs pieņem saņemto avotu. Arī atbildei jāatgriežas pa saskaņoto ceļu. Ja kāda trūkst, simptoms ir identisks, tāpēc ir vērts pierakstīt adrešu tabulu pirms konfigurācijas aizskaršanas.
Nosakiet, kuras adreses profilam jāsatur
Uzskaitiet galamērķus secībā: lietotnes tīklu, risinātāja adresi un publisko galapunktu, kas pabeidz pašu tuneli. Trešo nekad nedrīkst maršrutēt tunelī, jo ārējam savienojumam vajag ceļu, kas pastāv pirms tuneļa.
| 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 |
Iekļaujiet gan UDP, gan TCP DNS vajadzībām, jo no ieviešanām tiek gaidīts TCP atbalsts līdzās UDP, un bloķēts TCP ceļš dod lēnus, daļējus bojājumus, nevis tīrus. Ja privātā zona tiek apkalpota arī ar IPv6, līdzvērtīgais hosta izņēmums izmanto IPv6 adresi un prefiksu, un tas ir atsevišķs ieraksts.
Pierakstiet, ko profils jau aptver, pirms kaut ko pievienojat. Dublēts maršruts ir nekaitīgs, bet negaidīts esošs maršruts jums saka, ka profils ir projektēts citam adrešu plānam nekā tas, ko saņēmāt.
Pievienojiet hosta maršrutu caur savienojuma īpašnieku
Vietēji pārvaldītam vietējam Windows profilam maršruts pieder savienojumam, nevis mašīnas globālajai maršrutēšanas tabulai. Vispirms priekšskatiet papildinājumu, pēc tam piemērojiet to tādā pašā tvērumā, kādu izmanto profils.
Add-VpnConnectionRoute -ConnectionName 'Office VPN' -DestinationPrefix '10.90.0.53/32' -WhatIf Get-VpnConnection -Name 'Office VPN' | Select-Object -ExpandProperty Routes
Pirmā komanda priekšskata izmaiņas, neko neinstalējot, un otrā uzskaita maršrutus, kurus profils pašlaik satur. Microsoft Add-VpnConnectionRoute atsauce dokumentē viena lietotāja un visu lietotāju tvērumus; visu lietotāju profilam vajadzīgs savs tvēruma parametrs, un viena lietotāja komanda pret visu lietotāju profilu neizdodas vai nonāk nepareizā vietā.
Kad profils tiek pārvaldīts vai nāk no piegādātāja klienta, izmaiņa pieder tam īpašniekam. Pastāvīga sistēmas maršruta likšana uz savienojuma politikas darbojas, līdz politika tiek piemērota atkārtoti un maršruts pazūd, kas parasti notiek atbalsta zvanā, nevis testēšanas laikā. Šis bojājums ir kluss: maršruts pazūd, nosaukums pārstāj atrisināties, un neviens nesasaista abus notikumus. Ielieciet izmaiņu īpašnieka paša ierakstā, lai nākamā atkārtotā piemērošana to saturētu, nevis dzēstu.
Pēc piemērošanas atkārtoti pievienojiet profilu, tā vietā lai pieņemtu, ka maršruts ir stājies spēkā. Maršruta izmaiņas aktīvā savienojumā ne vienmēr tiek uztvertas, un atkārtota pievienošanās arī atveido stāvokli, kāds jūsu lietotājiem faktiski būs.
Pārbaudiet, kuru risinātāju klients faktiski izmantoja
Maršruts kontrolē paketes, kas adresētas risinātājam. Tas neizlemj, kuri nosaukumi uz turieni jāsūta, un šī izvēle ir atsevišķs mehānisms. Windows faktiskie nosaukumtelpas noteikumi var izvēlēties risinātāju katram domēnam, bet profila DNS iestatījumi nodrošina noklusējumu. Šie divi slāņi var nesaskanēt, neizraisot nekādu kļūdu, tāpēc tiešs vaicājums ir tikai puse pierādījuma.
Get-DnsClientNrptPolicy Resolve-DnsName app.svc.example -Server 10.90.0.53 -Type A
Pirmā komanda izdrukā spēkā esošo nosaukumtelpas politiku, un otrā tieši jautā privātajam risinātājam lietotnes nosaukumu. Tieša atbilde pierāda, ka ceļš un risinātājs darbojas; tā nepierāda, ka pašas lietotnes meklēšana izvēlējās šo serveri. Salīdziniet to ar parastu tā paša nosaukuma meklēšanu un ar atbildi, ko lietotne saņem.
Ņemiet vērā kešatmiņas un drošo DNS pārlūka līmenī, kas var pilnībā apiet sistēmas risinātāju lietotāja ievadītiem nosaukumiem. Meklēšanas piedēklis ir vēl viens maldinošs pavediens: tas paplašina īsu nosaukumu līdz pilnīgi kvalificētam un tam nav nekāda sakara ar to, kurš serveris atbild.
Pabeidziet, atkārtoti pievienojoties un atkārtojot parasto meklēšanu, pēc tam apstipriniet, ka parastā pārlūkošana joprojām ievēro apstiprināto politiku. Privātā risinātāja aizstāšana ar publisku, lai atrisinātu nesaistītu nosaukumu, nav labojums, un tas klusi pārvieto privātos vaicājumus tur, kur tiem nekad nevajadzēja nonākt.