Ваш раздзелены тунель дасягае праграмы, але не яе DNS-сервера
Раздзелены тунель можа маршрутызаваць падсетку праграмы і ўсё ж скідваць рэзалвер побач з ёй. Дадайце маршрут да хоста, затым праверце, які сервер Windows фактычна выбірае.
Маршрутызацыя падсеткі праграмы — гэта відавочная частка раздзеленага тунеля, і яна не ўся праца. Рэзалвер часта знаходзіцца на іншым адрасе, чым праграма, якой ён служыць, таму працоўны тунель можа пакінуць запыт па-за сабой. Профіль, які нясе 10.80.0.0/16 і больш нічога, адпраўляе запыт пра 10.90.0.53 праз лакальны інтэрфейс, дзе прыватнай зоны не існуе. Дадайце шлях да рэзалвера, затым праверце другую палову праблемы: які сервер кліент фактычна выбірае.
Міф: адзін маршрут пакрывае ўсю службу
Раздзелены тунель — гэта спіс пунктаў прызначэння, якія ідуць праз злучэнне, а не апісанне службы. Падсетка праграмы і адрас рэзалвера — два пункты прызначэння, і профіль можа несці адзін без другога. Калі гэта здараецца, праграма дасягальная па адрасе, але яе імя не вырашаецца, што выглядае як збой DNS, а не як прагал у маршрутызацыі.
Падсетка вакол рэзалвера таксама не пакрываецца аўтаматычна. Маршруту да хоста на адзін адрас дастаткова для гэтага рэзалвера, і ён не адкрывае яго суседзяў. У гэтым і сэнс маршруту да хоста: вузкі па задуме і лёгкі для забыцця, калі наступная служба з’явіцца ў той жа падсетцы.
Тры ўмовы павінны выконвацца, каб запыт працаваў: кліент маршрутызуе адрас рэзалвера праз тунель, шлюз прымае і перасылае гэты запыт, а рэзалвер прымае крыніцу, якую атрымлівае. Адказ таксама мусіць вярнуцца па ўзгодненым шляху. Калі не хапае хоць аднаго, сімптом аднолькавы, таму табліцу адрасоў варта запісаць да таго, як кранаць канфігурацыю.
Вызначце, якія адрасы профіль павінен несці
Пералічыце пункты прызначэння па парадку: сетка праграмы, адрас рэзалвера і публічная канчатковая кропка, якая завяршае сам тунель. Трэці ніколі нельга маршрутызаваць у тунель, бо знешняму злучэнню патрэбны шлях, які існуе да тунеля.
| 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 |
Уключыце і UDP, і TCP для DNS, бо ад рэалізацый чакаюць падтрымкі TCP нароўні з UDP, а заблакаваны шлях TCP дае павольныя, частковыя збоі замест чыстых. Калі прыватная зона абслугоўваецца таксама праз IPv6, эквівалентнае выключэнне для хоста выкарыстоўвае адрас і прэфікс IPv6 і ёсць асобным запісам.
Запішыце, што профіль ужо пакрывае, перш чым нешта дадаваць. Дублікат маршруту бясшкодны, але нечаканы існуючы маршрут кажа, што профіль быў распрацаваны для іншага плана адрасоў, чым той, які вам далі.
Дадайце маршрут да хоста праз уладальніка злучэння
Для лакальна кіраванага роднага профіля Windows маршрут належыць злучэнню, а не глабальнай табліцы маршрутызацыі машыны. Спачатку папярэдне прагледзьце даданне, затым ужыцца яго з той жа вобласцю, якую выкарыстоўвае профіль.
Add-VpnConnectionRoute -ConnectionName 'Office VPN' -DestinationPrefix '10.90.0.53/32' -WhatIf Get-VpnConnection -Name 'Office VPN' | Select-Object -ExpandProperty Routes
Першая каманда папярэдне паказвае змену, нічога не ўсталёўваючы, а другая пералічвае маршруты, якія профіль зараз нясе. Даведнік Microsoft па Add-VpnConnectionRoute апісвае вобласці для асобнага карыстальніка і ўсіх карыстальнікаў; профіль для ўсіх карыстальнікаў патрабуе ўласнага параметра вобласці, а каманда для асобнага карыстальніка супраць профіля для ўсіх карыстальнікаў ці не спрацоўвае, ці трапляе не туды.
Калі профіль кіруецца ці паходзіць ад кліента пастаўшчыка, змена належыць таму ўладальніку. Награмаджэнне пастаяннага сістэмнага маршруту па-над палітыкай злучэння працуе, пакуль палітыку не ўжывуць зноў і маршрут не знікне, што звычайна адбываецца падчас тэлефоннага звароту ў падтрымку, а не падчас тэставання. Гэты збой маўклівы: маршрут знікае, імя перастае вырашацца, і ніхто не звязвае дзве падзеі. Запішыце змену ў ўласны запіс уладальніка, каб наступнае паўторнае ўжыццё яе несла, а не сцірала.
Пасля ўжыцця перападключыце профіль, а не мяркуйце, што маршрут набыў моц. Змены маршрутаў на жывым злучэнні не заўсёды падхопліваюцца, і перападключэнне таксама ўзнаўляе стан, які вашы карыстальнікі фактычна будуць мець.
Праверце, які рэзалвер кліент фактычна выкарыстаў
Маршрут кіруе пакетамі, адрасаванымі рэзалверу. Ён не вырашае, якія імёны туды павінны пайсці, і гэты выбар — асобны механізм. У Windows эфектыўныя правілы прасторы імёнаў могуць выбіраць рэзалвер для кожнага дамена, а налады DNS профіля даюць значэнне па змаўчанні. Гэтыя два ўзроўні могуць разыходзіцца, не выдаючы ніякай памылкі, таму прамы запыт — гэта толькі палова доказаў.
Get-DnsClientNrptPolicy Resolve-DnsName app.svc.example -Server 10.90.0.53 -Type A
Першая каманда друкуе моцную палітыку прасторы імёнаў, а другая пытаецца ў прыватнага рэзалвера напроста пра імя праграмы. Прамы адказ даказвае, што шлях і рэзалвер працуюць; ён не даказвае, што ўласны запыт праграмы выбраў гэты сервер. Параўнайце яго са звычайным запытам таго ж імя і з адказам, які атрымлівае праграма.
Улічыце кэшы і бяспечны DNS на ўзроўні браўзера, які можа цалкам абыйсці сістэмны рэзалвер для імёнаў, набраных карыстальнікам. Пошукавы суфікс — яшчэ адна падманка: ён пашырае кароткае імя да поўнага і не мае ніякага дачынення да таго, які сервер адказвае.
Напрыканцы перападключыцеся і паўтарыце звычайны запыт, затым пацвердзіце, што звычайнае браўзінга па-ранейшаму трымаецца зацверджанай палітыкі. Замена прыватнага рэзалвера публічным, каб вырашыць непаляжанае імя, не ёсць выпраўленнем, і яна ціха пераносіць прыватныя запыты туды, куды іх ніколі не меркавалі.