Няма інтэрнэту ў VPN на Windows? Падазроны — пул адрасоў

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

Windows паказвае тунэль як падключаны і пазначае яго Без доступу да інтэрнэту, што людзі чытаюць як дзівацтва Windows. Гэта сцверджанне пра тое, што атрымаў кліент: няма прыдатнага шлюза па змаўчанні, няма працаздольнага рэзалвера і няма шляху назад для адрасоў унутры тунэля. Калі сервер — гэта Windows Incoming Connection, адзін параметр тлумачыць большасць такіх паведамленняў. Пазнака не з'яўляецца дыягназам, але яна звужае пошук да трох месцаў.

Прачытайце арэнду, перш чым яе змяніць

Выканайце ipconfig /all на кліенце і знайдзіце адаптар VPN сярод запісаў. Адрас, шлюз па змаўчанні і сервер DNS, якія ён паказвае, — гэта факты, якія вам патрэбныя, і яны часта адрозніваюцца ад таго, што адміністратар мяркуе выдадзеным.

Тры ўзоры адпавядаюць тром няспраўнасцям. Адрас у 169.254.0.0/16 азначае, што кліент не атрымаў нічога і сам сабе прысвоіў лакальны адрас канала. Праўдападобны адрас без шлюза азначае, што пул быў выдадзены без опцыі, якая дае кліенту маршрут па змаўчанні. Поўная арэнда, якая ўсё яшчэ нікуды не дасягае, указвае на перанакіраванне або трансляцыю на баку сервера.

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

Чаму аўтаматычнае прызначэнне можа пакінуць без шлюза

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

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

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

Тое ж непаразуменне ўзнікае, калі хтосьці чакае, што DHCP-сервер маршрутызатара LAN будзе абслугоўваць кліентаў тунэля. Шырокавяшчальнае выяўленне не перасякае маршрутызаваны тунэль, таму гэты сервер ніколі не бачыць запыту. Меркаванне пра адваротнае — самая частая прычына, чаму пул вінавацяць за кліента, які нічога ў яго не пытаў.

Задайце яўны дыяпазон, які сервер можа маршрутызаваць

Выберыце невялікі блок унутры падсеткі, да якой сервер можа дасягнуць, па-за дыяпазонам, які выдае маршрутызатар LAN, і па-за любым іншым пулам у сетцы. Калі сервер знаходзіцца на 172.20.10.0/24, а маршрутызатар займае 172.20.10.1, кароткі блок каля вяршыні гэтай падсеткі, скажам, ад 172.20.10.201 да 172.20.10.209, трымае арэнды тунэля далей ад выдачы, якой маршрутызатар ужо кіруе.

Увядзіце яго ва ўласцівасцях IPv4 для Incoming Connection, падключыце кліент зноў і прачытайце адаптар яшчэ раз, перш чым мяняць што-небудзь іншае. Другое чытанне пакажа, ці быў пул прычынай, ці проста адной з некалькіх няспраўнасцяў.

Гэтыя каманды выводзяць выніковую канфігурацыю і маршруты, якія кліент мае цяпер:

ipconfig /all
route print -4
Get-NetIPConfiguration -InterfaceAlias \"Incoming Connection\"

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

Адрас — гэта не шлях у інтэрнэт

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

Internet Connection Sharing — гэта кароткі шлях. Ён ператварае адаптар, які глядзіць у інтэрнэт, у агульны шлюз і вядзе ўласную адрасацыю, што можа перапісаць адрас гэтага адаптара і пакінуць існуючае правіла NAT, якое паказвае на значэнне, якога больш не існуе. Запішыце зыходныя наладкі, перш чым уключыць яго.

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

Спачатку выключыце знешні шлях

Ні адзін пул не дапаможа, калі тунэль ніколі не ўтворыцца. Пратакол вырашае, што павінен несці шлях: PPTP патрабуе TCP 1723 і GRE, гэта пратакол IP 47, а не порт; L2TP/IPsec патрабуе UDP 1701 плюс 500 і 4500; SSTP патрабуе TCP 443.

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

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

Падобныя артыкулы