Разделеният ви тунел достига до приложението, но не и до неговия 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 на ниво браузър, който може напълно да заобиколи системния резолвер за имена, въведени от потребителя. Суфиксът за търсене е друга заблуда: той разширява кратко име до напълно квалифицирано и няма нищо общо с това кой сървър отговаря.
Накрая свържете отново и повторете нормалната заявка, после потвърдете, че обикновеното сърфиране все още следва одобрената му политика. Замяната на частния резолвер с публичен, за да се реши несвързано име, не е поправка и тихо премества частните заявки там, където никога не са били предвидени.