Нови клијент хотспота заглављен на добијању IP није квар VPN-а

Телефон се повеже са хотспотом, остане на „Добијање IP адресе“ и на крају одустане. Природан закључак је да VPN на телефону омета DNS, па људи почну да уређују резолвере и додата правила. То је погрешна фаза. Клијент никада није добио локалну адресу, а без ње нема приступну тачку, нема резолвер и нема шта да проследи, тако да ниједно VPN подешавање на матичном телефону не може да објасни квар. Повезивање, додела локалне адресе и даље прослеђивање су три одвојене фазе и само последња укључује тунел.

Три фазе и у којој се налазите

Прво долази повезивање: клијент се придружи бежичној мрежи хотспота. Погрешна лозинка, неусклађеност WPA3 или проблем са компатибилношћу радија падају овде и клијент то обично каже. Друго је додела адресе: за IPv4 клијент тражи закуп и добија адресу плус локална подешавања приступне тачке, док IPv6 обично користи најаве рутера уместо DHCP-а, како описује AOSP документација о tethering-у. Треће је даљи приступ: матични телефон прослеђује дозвољени саобраћај на пут ка горе који је одабрао, а то може, али и не мора бити његов тунел.

Текст на клијенту вам каже фазу. Заглављивање на добијању адресе је друга фаза, пре него што иједан пакет крене на интернет. Повезан, са адресом, али ништа се не учитава јесте трећа фаза, где су битни усмеравање, имена и покривеност тунела. Дијагностиковати трећу фазу док је клијент заглављен у другој значи да петоминутни проблем са закупом постане поподне уређивања DNS-а.

Мит: усмерени VPN претвара локални DHCP у удаљени захтев

Усмерени тунел преноси IP пакете за одредишта која одабере. DHCP откривање је емитовање у сопственом сегменту хотспота, а tethering услуга на телефону одговара на њега локално, зато клијент може да добије адресу док је тунел активан. Само намерно премошћено или релејно решење шаље ту размену негде другде, а то је други распоред са другачијим потписом квара.

Дакле „VPN сервер не одговара на DHCP“ није дијагноза, то је грешка у моделу. Локални посредник је на телефону. Ако престане да одговара, разлози су локални: tethering услуга, ограничење броја клијената, базен закупа или клијент који никада није исправно завршио повезивање. Ништа од тога не живи на удаљеној страни тунела.

Шта радни постојећи клијент заиста доказује

Ако преносни рачунар који је већ био повезан још ради, а нови телефон не, хотспот и пут ка горе су углавном живи. То поређење је корисно и није доказ који је део крив, јер радни клијент можда само држи закуп од пре промене и тихо га обнавља.

Две локалне границе вреди проверити док сте тамо. Хотспот служи ограничен базен закупа и подесиво ограничење клијената, па уређај који се придружио и заспао може да држи адресу док нови чека. А клијент који памти статичку конфигурацију са друге мреже уопште неће тражити закуп, што споља изгледа исто и поправља се на клијенту, не на телефону.

Држите поређење локалним и реверзибилним

На уређају на коме правила то дозвољавају, упоредите једно придруживање новог клијента са неактивним па активним тунелом, држећи хотспот и клијент иначе непромењеним. Забележите верзије телефона и клијента, изабрани профил и тачну фазу која је пала. На управљаном телефону затражите одобрено поређење уместо искључивања спровођења ради чистијег теста.

Доследан квар закупа зависан од тунела користан је доказ о локалној политици или интеракцији имплементација. То није лиценца да почистите свако правило прослеђивања и NAT-а на уређају. Та правила штите неповезан саобраћај, а широко прихватање прослеђивања не објашњава зашто је локална DHCP услуга престала да одговара.

Не прекривајте закуп који недостаје нагађаном статичком адресом. Намерна статичка конфигурација тражи праву подмрежу, приступну тачку, план расподеле и проверу судара. Промена DNS-а на клијенту не даје ништа од тога и оставља следећи уређај са истим кваром.

Шта закуп не доказује

Добијање адресе доказује пријем у локалну мрежу, не заштиту тунелом телефона. Када клијент има закуп, процените пут надоле засебно: пролази ли саобраћај клијента заиста кроз телефон, разрешавају ли се упити тамо где очекујете и одговара ли спољашња адреса излазу који сте намеравали? То су питања треће фазе и заслужују сопствени тест уместо да се савију у придруживање.

Радите фазе по реду и квар престаје да се сели. Клијент заглављен на добијању адресе је локално питање tethering-а; клијент са адресом и без страница питање је прослеђивања или именовања; клијент са страницама и погрешним излазом питање је покривености тунела. Раздвајање тих случајева је већина отклањања проблема.