Чаму табліца маршрутаў VPN у Windows паказвае 0.0.0.0/1 і 128.0.0.0/1

Падключыцеся да VPN у Windows і адкрыйце табліцу маршрутаў — у ёй вылучаюцца два запісы: 0.0.0.0/1 і 128.0.0.0/1. Гэта не друкарская памылка, і яны не замяняюць маршрут па змаўчанні. Іх з'яўленне залежыць ад адной опцыі профілю, а гэтая пара — спосаб пабудовы поўнага тунелю, а не функцыя раздзеленага тунелю. Прачытайце опцыю, прэфікс і інтэрфейс разам, перш чым змяняць хоць адзін радок.

Што ўсталёўвае опцыя шлюза па змаўчанні

Опцыя профілю, якая пускае ўсё праз тунель, працуе шляхам дадання гэтых двух прэфіксаў. Зніміце опцыю — і яны знікнуць, пакінуўшы маршрут, які ахоплівае толькі падсетку, выдадзеную адаптару тунелю. Сцяжок кіруе парай; ён не перапісвае адзіны маршрут па змаўчанні. Таму пасля зняцця сцяжка табліца выглядае як частковае перапісванне, а не выдаленне.

0.0.0.0/1 ахоплівае ніжнюю палову прасторы IPv4, а 128.0.0.0/1 — верхнюю, таму разам яны ахопліваюць кожны адрас аднаадраснай дастаўкі. Кожны з іх больш канкрэтны за маршрут 0.0.0.0/0 па змаўчанні, а значыць, супастаўленне па найбольш доўгім прэфіксе накіроўвае звычайны трафік у тунель, пакуль фізічны маршрут па змаўчанні застаецца на месцы. Захоўваць гэты маршрут — не касметыка: пакеты, якія абгортваюць зашыфраванае карыснае начытанае, адрасаваныя публічнаму адрасу сервера і павінны выходзіць праз фізічны адаптар. Замяніце маршрут па змаўчанні замест таго, каб дзяліць яго, — і транспарт самога тунелю паспрабуе ўвайсці ў тунель, а гэта пятля, а не злучэнне.

Таму літаральны 0.0.0.0/0, які паказвае на адаптар VPN, варта спыніць і разгледзець. Убудаваны кліент звычайна такога не піша, значыць, ручны маршрут або канфігурацыя іншага кліента змянілі табліцу ў вас за спіной. Знайдзіце яго, перш чым адладжваць што-небудзь ніжэй.

Разбор таннейшы за захаванне шлюза

Разбор — практычны аргумент на карысць двух запісаў замест аднаго. Кліент валодае роўна двума маршрутамі, пакуль падключаны, і выдаляе іх пры адключэнні, пакідаючы тое, што фізічны адаптар трымае ў гэты момант. Кліент, які замяніў адзіны маршрут па змаўчанні, павінен быў бы памятаць папярэдні шлюз, і пасля змены арэнды DHCP мог бы аднавіць той, якога ўжо не існуе. Два ўласныя запісы такога стану не нясуць.

Іншыя кліенты прыходзяць да той жа канструкцыі. Профіль OpenVPN з redirect-gateway def1 усталёўвае гэтыя два прэфіксы замест выдалення маршруту па змаўчанні, і кліент Windows ідзе па той жа схеме з той самай прычыны маршрутызацыі.

Менавіта таму табліца можа выглядаць як поўны тунель, калі вы чакалі раздзялення. Пара — гэта тое, як будуецца поўны тунель, а не доказ памылкі раздзеленага тунелю. Калі профіль настроены выкарыстоўваць аддалены шлюз, маршрутызуецца ўсё, што б там ні дасягала адна мясцовая праграма.

Найбольшы прэфікс перамагае раней за любы метрык

Даўжыня прэфікса вызначае пошук раней за любое іншае поле. Метрык толькі разрывае нічыю паміж маршрутамі з аднолькавым прэфіксам, таму запіс /1 перамагае маршрут /0 па змаўчанні нават пры горшым метрыку. Прывязка да інтэрфейса вырашае, што застанецца, калі два маршруты дзеляць прэфікс і Windows павінен выбраць, які адаптар адправіць пакет.

route print -4
Get-NetRoute -AddressFamily IPv4 | Sort-Object DestinationPrefix
Find-NetRoute -RemoteIPAddress 10.50.5.20

Табліца раздзеленага тунелю трымае фізічны маршрут па змаўчанні, два паўмаршруты, маршрут для падсеткі тунелю і любы офісны прэфікс, які вы дадалі. Фізічны маршрут па змаўчанні можа мець ніжэйшы або вышэйшы метрык у залежнасці ад кліента і профілю, і пакуль існуе пара /1, гэтая розніца нічога не змяняе. Яна змяняе ўсё ў момант выдалення пары — менавіта тады выяўляюцца састарэлы шлюз або няправільны інтэрфейс. Чытайце ўсю табліцу, а не той адзін радок, які вы чакалі змяніць.

Выберыце аднаго ўласніка офіснага прэфікса

Для раздзеленага тунелю называйце толькі той прэфікс, які павінен ісці праз VPN, і выберыце адзін спосаб ім валодаць. Накіраванне маршруту на прызначаны адрас тунелю працуе, пакуль гэты адрас не зменіцца, а прывязка да інтэрфейса перажывае змену адраса, але ламаецца, калі індэкс прызначаецца нанова пасля перабудовы профілю. Камандлет, прывязаны да профілю, пазбаўляе ад абодвух праблем, але патрабуе профіль.

route -p add 10.50.0.0 mask 255.255.0.0 172.16.8.1
route -p add 10.50.0.0 mask 255.255.0.0 0.0.0.0 IF 31
Add-VpnConnectionRoute -ConnectionName Office -DestinationPrefix 10.50.0.0/16

Камандлет прывязвае прэфікс да названага профілю, таму маршрут з'яўляецца разам са злучэннем і знікае разам з ім, чаго і хоча кіраваны ноўтбук. Пастаянны маршрут перажывае перазагрузкі і перажывае профіль, які яго выклікаў, менавіта так спынены VPN пакідае запісы на гады. Выберыце адзін метад на прэфікс і запішыце выбар, бо пастаянны маршрут плюс маршрут профілю для аднаго прэфікса ствараюць дублікаты, якія балюча расплутваць пры разборы. Што б вы ні выбралі, уласнасць павінна быць бачная ў заяўцы, а не толькі на машыне.

Уласнасць — гэта пытанне, на якое адказвае гэты раздзел, а не сінтаксіс. Два ўласнікі аднаго прэфікса — гэта мадэль збою, якую варта пазбягаць.

Правярайце прызначэннем, а не вэб-сайтам

Праверце прызначэнне, якое павінна прайсці праз тунель, а не вэб-сайт, што паведамляе адрас выхаду. Find-NetRoute вяртае выбраны маршрут і адрас крыніцы, так што вы бачыце, што перамагло — офісны прэфікс ці фізічны маршрут па змаўчанні, — і пасля адкрываеце сам агульны рэсурс.

Find-NetRoute -RemoteIPAddress 10.50.5.20
Get-VpnConnection -Name Office

Сайт адрасу выхаду — слабая праверка, бо DNS, IPv6 і проксі браўзера могуць адправіць гэты запыт кожны сваім шляхам. IPv4 і IPv6 таксама маюць асобныя налады ў адным дыялогу, і зняцце аднаго сцяжка пакідае другое сямейства некранутым, таму двухстэкавая машына можа весці IPv6 праз тунель, пакуль IPv4 ідзе па маршруце раздзялення. Праверце абодва сямействы, перш чым называць профіль раздзеленым. Калі маршрут правільны, а служба ўсё яшчэ не працуе, пакінуты ўзровень — фільтраванне, а не маршрутызацыя.

Файрвол, якім кіруе кліент, можа блакаваць офісную падсетку пры бездакорнай табліцы маршрутаў. Гэтая палітыка належыць таму, хто рассылаў профіль, а не таму, хто рэдагуе маршруты.