Вашиот поделен тунел стигнува до апликацијата, но не до нејзиниот 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 на ниво на прелистувач, што може целосно да го заобиколи системскиот резолвер за имиња што ги внел корисникот. Наставката за пребарување е уште една лажна трага: таа го проширува краткото име во целосно квалификувано и нема никаква врска со тоа кој сервер одговара.
Завршете со повторно поврзување и повторување на нормалното пребарување, потоа потврдете дека обичното прелистување и понатаму ја следи својата одобрена политика. Замената на приватниот резолвер со јавен за да се реши неповрзано име не е поправка и тивко ги преместува приватните барања таму каде што никогаш не требало да одат.