Раздзелены тунель у Windows: скрынка шлюза і адсутны прэфікс
Windows пускае ўсё праз тунель, пакуль вы не здымеце адзін сцяжок, а потым занадта мала, пакуль не дадасце падсетку. Абодва належаць да адной змены.
Тунель паведамляе, што злучаны, і вікі ўсё яшчэ загружаецца. Потым загрузка спыняецца, і агульны рэсурс на паліцы перастае адказваць. Тунель зрабіў сваю працу, а профіль проста заявіў кожны пункт прызначэння.
Windows разглядае VPN-злучэнне як рашэнне аб маршруце. Пакуль гэта рашэнне не звужана, машына паводзіць сябе так, нібы пераехала ў офіс.
Чаму працоўны тунель адчуваецца як збой
Профіль, якому дазволена выкарыстоўваць аддалены шлюз, устанаўлівае маршрут па змаўчанні праз тунель. Кожны пункт прызначэння, які не знаходзіцца на лакальным звяне, тады выходзіць праз офісны файрвол. Лакальныя агульныя рэсурсы перастаюць адказваць, бо іх трафік цяпер едзе на іншы кантынент і вяртаецца. Нішто ў стане кліента гэтага не адлюстроўвае.
Сімптомы заблытаныя наўмысна. Развязанне імёнаў можа яшчэ працаваць, пакуль агульны рэсурс сканчае час чакання, або наадварот. Карыстальнік паведамляе, што VPN зламаны, кліент паведамляе, што ўсё добра, і абодва сцвярджэнні дакладныя.
Сцяжок, які хаваецца ў дыялогу IPv4
Налада ляжыць на некалькі дыялогаў глыбей. Адкрыйце ncpa.cpl, пстрыкніце правай кнопкай па злучэнні, затым уласцівасці IPv4, затым Дадаткова, і здыміце опцыю, якая дазваляе злучэнню стаць аддаленым шлюзам па змаўчанні. Гэтая адна скрынка вырашае, ці з'яўляецца профіль поўным тунэлем. Усё астатняе ў профілі па-ранейшаму дзейнічае.
Параўнайце route print -4 да і пасля перападключэння. Запіс 0.0.0.0, які раней паказваў на тунель, павінен знікнуць, а карпаратыўныя прэфіксы павінны застацца.
route print -4 | findstr /c:"0.0.0.0"
Get-VpnConnection -Name 'Work VPN' | Select-Object Name, SplitTunneling, Routes
Змяніць метрыку інтэрфейса не замена. Метрыка вырашае толькі паміж двума канкуруючымі маршрутамі па змаўчанні, і кліент, які пераўсталёўвае свой маршрут па змаўчанні пры кожным злучэнні, перамагае ў гэтым спаборніцтве незалежна ад зададзенага ліку.
Прэфікс, якога ніхто не ўпісаў
Раздзелены тунель адкрывае менавіта тыя прэфіксы, што запісаныя ў профілі. Офісная падсетка, дададзеная пасля напісання профілю, застаецца недасяжнай, пакуль тунель цалкам здаровы. Тады справаздача прыходзіць як адзін зламаны сервер, а не як зламаны VPN.
Маршрут, дададзены ўручную, закрывае прагал, пакуль адрас шлюза не зменіцца. Запісаць прэфікс у злучэнні трывалей, бо прэфікс тады ідзе за злучэннем, а не за ўгаданым адрасам.
route -p add 172.20.8.0 mask 255.255.255.0 10.8.0.1
Add-VpnConnectionRoute -ConnectionName 'Work VPN' -DestinationPrefix 172.20.8.0/24
Get-VpnConnection -Name 'Work VPN' | Select-Object -ExpandProperty Routes
Чытайце захаваны спіс і жывую табліцу разам. Захаваны прэфікс можа існаваць, пакуль табліца яго ніколі не атрымае, што здараецца, калі агент кіравання фільтруе маршруты пасля ўздыму злучэння. Бывае і наадварот: маршрут у рэестры паказвае на адаптар, які выключаны. Ні адзін з выглядаў асобна не расказвае ўсё.
Даказаць вынік пасля перазагрузкі
Прасочыце ў абодвух кірунках і развяжыце па імені. Публічная трасіроўка павінна выходзіць праз пастаўшчыка, унутраная трасіроўка павінна ўваходзіць у тунель, а ўнутраны хост павінен адказваць па імені, а не толькі па адрасе.
tracert -4 www.example.com
tracert -4 wiki.corp.example
ping -4 fileserver.corp.example
ping -4 172.20.8.20
Паўтарыце пасля адключэння, перападключэння і адной перазагрузкі. Прэфікс, які перажывае ручное перападключэнне і знікае пасля перазапуску, ніколі не быў захаваны ў профілі.
Трымайце прынтар і NAS у тэсце таксама, бо раздзелены тунель, які адсякае прылады побач з ноўтбукам, вырашыў адну праблему, стварыўшы меншую і больш раздражняльную. Даведка Microsoft па Add-VpnConnectionRoute — гэта месца, дзе зверыць напісанне параметраў з версіяй вашага модуля.