Новы кліент хотспота, які застрэў на атрыманні IP-адраса, — не збой VPN

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

Тры стадыі, і на якой вы знаходзіцеся

Спачатку далучэнне: кліент далучаецца да бесправадной сеткі хотспота. Няправільны пароль, неадпаведнасць WPA3 або праблема сумяшчальнасці радыё падаюць тут, і кліент звычайна пра гэта паведамляе. Другая — прызначэнне адраса: для IPv4 кліент запытвае арэнду і атрымлівае адрас плюс лакальныя налады шлюза, а IPv6 звычайна выкарыстоўвае аб’явы маршрутызатара замест DHCP, як апісвае дакументацыя AOSP па тэтэрынгу. Трэцяя — далейшы доступ: тэлефон-хасціра перадае дазволены трафік на абраны ім шлях уверх, які можа быць яго тунелем, а можа і не.

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

Міф: маршрутызаваны VPN робіць лакальны DHCP аддаленым запытам

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

Таму «сервер VPN не адказвае на DHCP» — гэта не дыягназ, а памылка мадэлі. Лакальны пасярэднік знаходзіцца на тэлефоне. Калі ён перастае адказваць, прычыны лакальныя: служба тэтэрынгу, ліміт кліентаў, пул арэнды або кліент, які так і не завяршыў далучэнне як трэба. Нішто з гэтага не жыве на аддаленым баку тунеля.

Што насамрэч даказвае працаздольны існуючы кліент

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

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

Трымайце параўнанне лакальным і абарачальным

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

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

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

Што арэнда не даказвае

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

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