Nova hotspot-kliento blokita ĉe akiri IP-adreson ne estas VPN-difekto

Telefono aliĝas al la hotspot, restas ĉe «Akirante IP-adreson» kaj fine rezignas. La natura konkludo estas, ke la VPN de la telefono malhelpas DNS, do homoj komencas redakti solvilojn kaj aldonitajn regulojn. Tio estas la malĝusta etapo. La kliento neniam ricevis lokan adreson, kaj sen ĝi ĝi havas nek pordegon, nek solvilon, nek ion por plusendi, do neniu VPN-agordo sur la gastiga telefono povas klarigi la malsukceson. Asociiĝo, loka adresatribuo kaj plua plusendado estas tri apartaj etapoj, kaj nur la lasta koncernas la tunelon.

La tri etapoj, kaj en kiu vi estas

Unue venas asociiĝo: la kliento aliĝas al la sendrata reto de la hotspot. Malĝusta pasvorto, WPA3-miskongruo aŭ radia kongrueca problemo malsukcesas ĉi tie, kaj la kliento kutime diras tion. Due venas adresatribuo: por IPv4 la kliento petas luon kaj ricevas adreson plus lokajn pordegajn agordojn, dum IPv6 kutime uzas enkursigilajn anoncojn anstataŭ DHCP, kiel priskribas la AOSP-dokumentaro pri tethering. Trie venas plua aliro: la gastiga telefono plusendas permesitan trafikon al tiu suprenvoja itinero, kiun ĝi elektis, kiu povas esti aŭ ne esti ĝia tunelo.

La vortigo sur la kliento diras al vi la etapon. Blokita ĉe akiri adreson estas la dua etapo, antaŭ ol iu ajn pako forlasas al la interreto. Konektita, kun adreso, sed nenio ŝargiĝas estas la tria etapo, kie enkursigado, nomoj kaj tunela kovrado ĉiuj gravas. Diagnozi la trian etapon dum la kliento estas blokita en la dua estas kiel kvinninuta lua problemo fariĝas posttagmezo da DNS-redaktado.

La mito: enkursigita VPN igas lokan DHCP malproksima peto

Enkursigita tunelo movas IP-pakojn por la cellokoj, kiujn ĝi elektas. DHCP-malkovro estas elsendo en la propra segmento de la hotspot, kaj la tethering-servo sur la telefono respondas ĝin loke, tial la kliento povas ricevi adreson dum la tunelo estas aktiva. Nur intence pontita aŭ relajita dezajno sendas tiun interŝanĝon aliloken, kaj tio estas alia aranĝo kun alia malsukcesa signaturo.

Do «la VPN-servilo ne respondas al DHCP» ne estas diagnozo, ĝi estas modeleraro. La loka peranto estas sur la telefono. Se ĝi ĉesas respondi, la kaŭzoj estas lokaj: la tethering-servo, la klienta limo, la lua provizo aŭ kliento, kiu neniam ĝuste finis asociiĝon. Neniu el tiuj vivas sur la malproksima flanko de la tunelo.

Kion funkcianta ekzistanta kliento efektive pruvas

Se tekkomputilo, kiu jam estis konektita, ankoraŭ funkcias dum la nova telefono ne, la hotspot kaj la suprenvoja itinero estas ĝenerale vivaj. Tiu komparo estas utila kaj ĝi ne estas pruvo de tio, kiu komponanto kulpas, ĉar la funkcianta kliento eble simple tenas luon el antaŭ la ŝanĝo kaj kviete renovigas ĝin.

Du lokaj limoj indas kontroli dum vi estas tie. La hotspot servas finhavan luan provizon kaj konfigureblan klientan limon, do aparato, kiu aliĝis kaj dormis, povas teni adreson dum nova atendas. Kaj kliento, kiu memoras statikan agordon el alia reto, tute ne petos luon, kio ekstere aspektas idente kaj estas riparata ĉe la kliento, ne sur la telefono.

Tenu la komparon loka kaj malfarebla

Sur aparato, kie politiko permesas, komparu unu aliĝon de nova kliento kun la tunelo neaktiva kaj poste aktiva, tenante la hotspot kaj la klienton alie senŝanĝaj. Notu la versiojn de telefono kaj kliento, la elektitan profilon kaj la precizan etapon, kiu malsukcesis. Sur administrata telefono, petu la aprobitan komparon anstataŭ malŝalti plenumadon por akiri pli puran teston.

Konsekvenca luo-malsukceso dependa de la tunelo estas utila pruvo pri loka politiko aŭ pri efektiviga interagado. Ĝi ne estas permeso purigi ĉiun plusendan kaj NAT-regulon sur la aparato. Tiuj reguloj protektas nerilatan trafikon, kaj larĝa plusenda akcepto ne klarigas, kial loka DHCP-servo ĉesis respondi.

Ankaŭ ne kovru mankan luon per divenita statika adreso. Intenca statika agordo bezonas la realan subreton, la pordegon, la atribuan planon kaj kolizian kontrolon. Ŝanĝi la DNS de la kliento donas neniun el tiuj, kaj ĝi lasas la sekvan aparaton kun la sama malsukceso.

Kion luo ne pruvas

Akiri adreson pruvas eniron al la loka reto, ne protekton per la tunelo de la telefono. Post kiam la kliento havas luon, taksu la malsupran itineron memstare: ĉu la trafiko de la kliento vere iras tra la telefono, ĉu serĉoj solviĝas tie, kie vi atendas, kaj ĉu la ekstera adreso kongruas kun la eliro, kiun vi celis? Tiuj estas demandoj de la tria etapo kaj ili meritas sian propran teston anstataŭ esti falditaj en la aliĝon.

Laboru la etapojn laŭ ordo kaj la malsukceso ĉesas moviĝi. Kliento blokita ĉe akiri adreson estas loka tethering-demando; kliento kun adreso kaj sen paĝoj estas plusenda aŭ noma demando; kliento kun paĝoj kaj malĝusta eliro estas tunela kovrado-demando. Teni ilin apartaj estas la plej granda parto de la sencimigado.