Umaabot ang split tunnel mo sa app pero hindi sa DNS server nito
Maaaring i-route ng split tunnel ang subnet ng app at iwan pa rin ang resolver sa tabi nito. Idagdag ang host route, pagkatapos tingnan kung aling server ang aktwal na pinipili ng Windows.
Ang pag-route ng subnet ng app ay ang halatang bahagi ng split tunnel, at hindi ito ang buong gawain. Madalas na nakaupo ang resolver sa ibang address kaysa sa app na pinaglilingkuran nito, kaya ang gumaganang tunnel ay maaari pa ring iwan ang lookup sa labas nito. Ang profile na may 10.80.0.0/16 at wala nang iba ay nagpapadala ng query para sa 10.90.0.53 sa lokal na interface, kung saan walang pribadong zone. Idagdag ang landas ng resolver, pagkatapos tingnan ang ikalawang kalahati ng problema: kung aling server ang aktwal na pinipili ng client.
Mito: isang ruta lang ang sumasaklaw sa buong serbisyo
Ang split tunnel ay listahan ng mga destinasyong dumadaan sa koneksyon, hindi paglalarawan ng serbisyo. Ang subnet ng app at ang address ng resolver ay dalawang destinasyon, at maaaring dalhin ng profile ang isa nang wala ang isa. Kapag nangyari iyon, naa-access ang app sa pamamagitan ng address habang nabigo ang pangalan nito, na mukhang sira ng DNS kaysa butas sa pag-route.
Ang subnet sa paligid ng resolver ay hindi rin awtomatikong sakop. Ang host route sa isang address ay sapat para sa resolver na iyon at hindi nagbubukas ng mga kapitbahay nito. Iyon ang punto ng host route: makitid sa disenyo, at madaling kalimutan kapag lumitaw ang susunod na serbisyo sa parehong subnet.
Tatlong bagay ang dapat totoo para gumana ang lookup: ini-route ng client ang address ng resolver sa tunnel, tinatanggap at ipinapasa ng gateway ang kahilingang iyon, at tinatanggap ng resolver ang pinagmulang natatanggap nito. Kailangan ding bumalik ang sagot sa napagkasunduang landas. Kapag may kulang sa mga ito, pareho ang sintomas, kaya sulit na isulat ang talahanayan ng address bago hawakan ang isang configuration.
Tukuyin kung aling mga address ang dapat dalhin ng profile
Ilista ang mga destinasyon sa pagkakasunod-sunod: ang network ng app, ang address ng resolver at ang pampublikong endpoint na nagtatapos sa tunnel mismo. Ang pangatlo ay hindi dapat i-route sa loob ng tunnel, dahil ang panlabas na koneksyon ay nangangailangan ng landas na umiiral bago ang tunnel.
| 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 |
Isama ang UDP at TCP para sa DNS, dahil inaasahang susuportahan ng mga implementasyon ang TCP kasama ng UDP, at ang naka-block na landas ng TCP ay gumagawa ng mabagal at bahagyang pagkabigo kaysa malinis. Kung ang pribadong zone ay pinaglilingkuran din sa pamamagitan ng IPv6, ang katumbas na host exception ay gumagamit ng IPv6 address at prefix at hiwalay na entry.
Itala kung ano ang sakop na ng profile bago magdagdag ng anuman. Ang doble na ruta ay walang harm, ngunit ang hindi inaasahang umiiral na ruta ay nagsasabi na ang profile ay dinisenyo para sa ibang plano ng address kaysa sa natanggap mo.
Idagdag ang host route sa pamamagitan ng may-ari ng koneksyon
Para sa lokal na pinamamahalaang katutubong profile ng Windows, ang ruta ay pag-aari ng koneksyon at hindi ng pandaigdigang routing table ng makina. I-preview muna ang pagdaragdag, pagkatapos ay ilapat ito sa parehong saklaw na ginagamit ng profile.
Add-VpnConnectionRoute -ConnectionName 'Office VPN' -DestinationPrefix '10.90.0.53/32' -WhatIf Get-VpnConnection -Name 'Office VPN' | Select-Object -ExpandProperty Routes
Ang unang command ay nag-preview ng pagbabago nang walang ini-install, at ang pangalawa ay naglilista ng mga rutang dinadala ng profile ngayon. Ang reference ng Add-VpnConnectionRoute ng Microsoft ay nagdodokumento ng mga saklaw para sa bawat user at para sa lahat ng user; ang profile para sa lahat ng user ay nangangailangan ng sarili nitong parameter ng saklaw, at ang command para sa bawat user laban sa profile para sa lahat ng user ay nabigo o napupunta sa maling lugar.
Kapag ang profile ay pinamamahalaan o nagmumula sa client ng vendor, ang pagbabago ay pag-aari ng may-ari na iyon. Ang pagpatong ng permanenteng system route sa ibabaw ng patakaran ng koneksyon ay gumagana hanggang sa muling ilapat ang patakaran at mawala ang ruta, na karaniwang nangyayari sa tawag sa suporta at hindi sa pagsubok. Tahimik ang pagkabigong iyon: nawawala ang ruta, humihinto ang pagresolba ng pangalan, at walang nag-uugnay sa dalawang pangyayari. Ilagay ang pagbabago sa sariling rekord ng may-ari upang dalhin ito ng susunod na muling paglalapat sa halip na burahin.
Pagkatapos ilapat, muling ikonekta ang profile sa halip na ipagpalagay na nagkabisa ang ruta. Hindi laging nakukuha ang mga pagbabago ng ruta sa aktibong koneksyon, at ang muling pagkonekta ay nagre-reproduce din ng estado na talagang mararanasan ng iyong mga user.
Tingnan kung aling resolver ang aktwal na ginamit ng client
Kinokontrol ng ruta ang mga packet na naka-address sa resolver. Hindi nito pinagpapasyahan kung aling mga pangalan ang dapat ipadala doon, at ang pagpiling iyon ay hiwalay na mekanismo. Sa Windows, ang mabisang mga tuntunin ng namespace ay maaaring pumili ng resolver sa bawat domain, habang ang mga setting ng DNS ng profile ay nagbibigay ng default. Maaaring hindi magkasundo ang dalawang antas na ito nang walang anumang error, kaya ang direktang query ay kalahati lamang ng ebidensya.
Get-DnsClientNrptPolicy Resolve-DnsName app.svc.example -Server 10.90.0.53 -Type A
Ang unang command ay nagpi-print ng umiiral na patakaran ng namespace, at ang pangalawa ay direktang nagtatanong sa pribadong resolver ng pangalan ng app. Ang direktang sagot ay nagpapatunay na gumagana ang landas at resolver; hindi nito pinapatunayan na pinili ng sariling lookup ng app ang server na iyon. Ihambing ito sa normal na lookup ng parehong pangalan at sa sagot na natatanggap ng app.
Isaalang-alang ang mga cache at secure na DNS sa antas ng browser, na maaaring lubusang laktawan ang resolver ng system para sa mga pangalang tina-type ng user. Ang search suffix ay isa pang mapanlinlang na bakas: pinalalawak nito ang maikling pangalan sa ganap na kwalipikadong pangalan at walang kinalaman sa kung aling server ang sumasagot.
Tapusin sa pamamagitan ng muling pagkonekta at pag-uulit ng normal na lookup, pagkatapos ay kumpirmahin na ang ordinaryong pag-browse ay sumusunod pa rin sa aprubadong patakaran nito. Ang palitan ang pribadong resolver ng pampubliko upang maresolba ang walang kaugnayang pangalan ay hindi pag-aayos, at tahimik nitong inililipat ang mga pribadong query sa lugar na hindi nila dapat puntahan.