Ang bagong hotspot client na natigil sa pagkuha ng IP ay hindi sira ng VPN

Sumasama ang telepono sa hotspot, tumitigil sa «Kumukuha ng IP address», at sa huli ay sumusuko. Ang natural na konklusyon ay ang VPN ng telepono ay nakikialam sa DNS, kaya nagsisimulang i-edit ng mga tao ang mga resolver at idinagdag na panuntunan. Iyon ang maling yugto. Hindi kailanman nakatanggap ang client ng lokal na address, at wala nito ay wala siyang gateway, walang resolver at walang maipapasa, kaya walang setting ng VPN sa host phone ang makapagpapaliwanag ng pagkabigo. Ang pagsasama, paglalaan ng lokal na address at pagpasa ay tatlong hiwalay na yugto, at ang huling yugto lamang ang may kinalaman sa tunnel.

Ang tatlong yugto, at kung alin ang kinalalagyan mo

Una ang pagsasama: sumasama ang client sa wireless network ng hotspot. Nabibigo rito ang maling password, hindi pagtutugma ng WPA3 o problema sa compatibility ng radyo, at karaniwang sinasabi ito ng client. Pangalawa ang paglalaan ng address: para sa IPv4 humihingi ang client ng lease at tumatanggap ng address at lokal na setting ng gateway, samantalang ang IPv6 ay karaniwang gumagamit ng anunsyo ng router sa halip na DHCP, gaya ng inilalarawan ng dokumentasyon ng AOSP sa tethering. Pangatlo ang paglabas: ipinapasa ng host phone ang pinapayagang trapiko sa piniling upstream na landas, na maaaring siyang tunnel nito o hindi.

Sinasabi ng teksto sa client ang yugto. Ang natigil sa pagkuha ng address ay ikalawang yugto, bago lumabas ang anumang packet patungong internet. Nakakonekta, may address, ngunit walang naglo-load ay ikatlong yugto, kung saan mahalaga ang routing, mga pangalan at saklaw ng tunnel. Ang mag-diagnose ng ikatlong yugto habang natigil ang client sa ikalawa ay kung paanong ang limang minutong problema sa lease ay nagiging isang hapon ng pag-edit ng DNS.

Ang mito: binabago ng naka-route na VPN ang lokal na DHCP tungong malayong kahilingan

Inililipat ng naka-route na tunnel ang mga IP packet para sa mga destinasyong pinipili nito. Ang pagtuklas ng DHCP ay broadcast sa sariling segment ng hotspot, at sinasagot ito ng serbisyo ng tethering sa telepono nang lokal, kaya nakakakuha ng address ang client habang nakaupo ang tunnel. Tanging sadyang naka-bridge o na-relay na disenyo ang nagpapadala ng palitan na iyon sa ibang lugar, at iyon ay ibang kaayusan na may ibang lagda ng pagkabigo.

Kaya «hindi sumasagot ang VPN server sa DHCP» ay hindi diagnosis, ito ay pagkakamali ng modelo. Nasa telepono ang lokal na broker. Kung tumigil ito sa pagsagot, lokal ang mga dahilan: ang serbisyo ng tethering, ang limitasyon ng client, ang pool ng lease o isang client na hindi kailanman nagtapos ng pagsasama nang maayos. Wala sa mga iyon ang nakatira sa malayong panig ng tunnel.

Ano ang tunay na pinapatunayan ng gumaganang umiiral na client

Kung gumagana pa ang isang laptop na nakakonekta na samantalang ang bagong telepono ay hindi, ang hotspot at ang upstream na landas ay buhay sa pangkalahatan. Kapaki-pakinabang ang paghahambing na iyon at hindi ito patunay kung aling bahagi ang may kasalanan, dahil ang gumaganang client ay maaaring hawak lamang ang lease mula bago ang pagbabago at tahimik na nagre-renew nito.

Dalawang lokal na limitasyon ang sulit suriin habang naroon ka. Naghahain ang hotspot ng may hanggang pool ng lease at naikokonpigurang limitasyon ng client, kaya ang device na sumama at natulog ay maaaring humawak ng address habang may naghihintay na bago. At ang client na naaalala ang static na konfigurasyon mula sa ibang network ay hindi hihingi ng lease, na mukhang pareho mula sa labas at inaayos sa client, hindi sa telepono.

Panatilihing lokal at maibabalik ang paghahambing

Sa device na pinapayagan ng patakaran, ihambing ang isang pagsama ng bagong client na hindi aktibo ang tunnel at pagkatapos ay aktibo, habang hindi binabago ang hotspot at client sa iba pang aspeto. Itala ang mga bersyon ng telepono at client, ang piniling profile at ang eksaktong yugtong nabigo. Sa pinamamahalaang telepono, hilingin ang aprubadong paghahambing sa halip na patayin ang pagpapatupad para sa mas malinis na pagsubok.

Ang tuloy-tuloy na pagkabigong pang-lease na nakadepende sa tunnel ay kapaki-pakinabang na ebidensya tungkol sa lokal na patakaran o interaksyon ng implementasyon. Hindi ito lisensya para burahin ang bawat panuntunan ng pagpasa at NAT sa device. Pinoprotektahan ng mga panuntunang iyon ang walang kaugnayang trapiko, at hindi ipinapaliwanag ng malawak na pagtanggap sa pagpasa kung bakit tumigil sa pagsagot ang isang lokal na serbisyo ng DHCP.

Huwag takpan ang kulang na lease ng hinulaang static na address. Ang sadyang static na konfigurasyon ay nangangailangan ng tunay na subnet, gateway, plano ng alokasyon at pagsusuri ng banggaan. Walang ibinibigay ang pagbabago ng DNS ng client sa mga iyon, at iniiwan nito ang susunod na device sa parehong pagkabigo.

Ano ang hindi pinapatunayan ng lease

Ang pagkuha ng address ay nagpapatunay ng pagtanggap sa lokal na network, hindi ng proteksyon ng tunnel ng telepono. Kapag may lease na ang client, suriin ang pababang landas nang mag-isa: dumadaan ba talaga ang trapiko ng client sa telepono, nalulutas ba ang mga lookup kung saan mo inaasahan, at tumutugma ba ang panlabas na address sa exit na nilalayon mo? Mga tanong ng ikatlong yugto ang mga iyon at karapat-dapat silang magkaroon ng sariling pagsubok sa halip na itiklop sa pagsama.

Isagawa ang mga yugto nang sunud-sunod at titigil ang pagkabigo sa paglipat. Ang client na natigil sa pagkuha ng address ay lokal na tanong ng tethering; ang client na may address pero walang pahina ay tanong ng pagpasa o pagpapangalan; ang client na may pahina pero maling exit ay tanong ng saklaw ng tunnel. Ang paghiwalay sa mga ito ang malaking bahagi ng pag-debug.