VPN у Windows паказва 255.255.255.255: маска няправільная?

Тунель падключаецца, вы адкрываеце звесткі пра адаптар, і маска паказвае 255.255.255.255. У параўнанні з 255.255.255.0 офіснай лакальнай сеткі гэта выглядае паломкай, і звычайна менавіта тут пачынаецца памылка. У злучэнні «пункт-пункт» маска хоста — правільнае апісанне лакальнага канца, а аддаленыя сеткі прыходзяць як маршруты, а не як далучаная падсетка. Прыведзеная ніжэй працэдура падзяляе два пытанні, каб вы не перабудоўвалі працоўную вобласць DHCP толькі дзеля выпраўлення адлюстраванага значэння.

Злучэнне «пункт-пункт» — не сегмент Ethernet

Інтэрфейсу Ethernet патрэбна маска падсеткі, бо кожны адрас у гэтым дыяпазоне патэнцыйна дасягальны па тым жа кабелі. Тунель у стылі PPP мае роўна аднаго партнёра на другім канцы. Тут няма шырокавешчальнага дамена, няма ARP і няма прычыны, па якой лакальны адрас павінен апісваць дыяпазон.

Узгадненне адрасоў для такой мадэлі вызначана ў RFC 1332, дзе апісана, як два канцы дамаўляюцца пра свае адрасы. Чаго ён не робіць — не перадае кліенту офісную лакальную сетку як непасрэдна далучаную. Кліент даведваецца, дзе знаходзіцца офіс, усталёўваючы маршруты праз злучэнне, і менавіта гэтыя маршруты фактычна вызначаюць дасягальнасць.

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

Крок 1: пацвердзіце мадэль інтэрфейса

Паглядзіце, што гэта за адаптар, перш чым судзіць пра тое, што ён паведамляе. Радок апісання вызначае драйвер, а даўжыня прэфікса ў прызначаным адрасе пацвярджае, пра што дамовіўся кліент:

Get-NetAdapter | Select-Object Name,InterfaceDescription,Status,ifIndex
Get-NetIPAddress -InterfaceAlias 'Corp VPN' | Select-Object IPAddress,PrefixLength,PrefixOrigin
Get-NetIPInterface -InterfaceAlias 'Corp VPN' | Select-Object AddressFamily,ConnectionState,NlMtu

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

Крок 2: прачытайце маршрут для праблемнага прызначэння

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

Get-NetRoute -InterfaceAlias 'Corp VPN' | Select-Object DestinationPrefix,NextHop,RouteMetric
Find-NetRoute -RemoteIPAddress 10.24.6.15
route print -4

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

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

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

Крок 3: аддзяліце вырашэнне імёнаў ад доступу да службы

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

Resolve-DnsName files.corp.example.internal
Get-DnsClientServerAddress -InterfaceAlias 'Corp VPN'
Test-NetConnection -ComputerName 10.24.6.15 -Port 445

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

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

Адкат: не перабудоўвайце DHCP з-за адлюстраванага значэння

Калі вы ўжо пачалі мяняць службу адрасацыі, спыніцеся і праверце, ці нешта з змененага з’яўляецца нясучым. Перастварэнне вобласці, паўторная выдача арэнды або перамяшчэнне пула змяняе стан, ад якога залежаць іншыя кліенты, і нішто з гэтага не апраўдана маскай хоста на адаптары «пункт-пункт».

Get-DnsClientServerAddress -InterfaceAlias 'Corp VPN'
Find-NetRoute -RemoteIPAddress 10.24.6.15
Test-NetConnection -ComputerName files.corp.example.internal -Port 445

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

Затым запішыце, што насамрэч азначала маска, бо наступны чалавек адкрые той жа дыялог і прыйдзе да той жа памылковай высновы. Адно сказ у нататках профілю пра тое, што тунель «пункт-пункт» і аддаленыя падсеткі прыходзяць як маршруты, зэканоміць усё расследаванне наступным разам.