Nový klient hotspotu uvízlý na získávání IP adresy není závada VPN
Přidružení, místní DHCP leasing a další předávání jsou tři fáze. Zařízení uvízlé na získávání adresy se k VPN nikdy nedostalo, takže přestaňte upravovat DNS.
Telefon se připojí k hotspotu, zůstane viset na „Získávání IP adresy“ a nakonec to vzdá. Přirozený závěr je, že VPN v telefonu zasahuje do DNS, a lidé začnou upravovat resolvery a přidaná pravidla. To je špatná fáze. Klient nikdy nedostal místní adresu, a bez ní nemá bránu, resolver ani co předávat, takže žádné nastavení VPN v hostitelském telefonu selhání nevysvětluje. Přidružení, přidělení místní adresy a další předávání jsou tři oddělené fáze a tunel se týká jen té poslední.
Tři fáze a ve které jste
Nejprve přichází přidružení: klient se připojí k bezdrátové síti hotspotu. Špatné heslo, neshoda WPA3 nebo problém s kompatibilitou rádia selhávají tady a klient to obvykle řekne. Druhé je přidělení adresy: u IPv4 klient požádá o leasing a dostane adresu plus místní nastavení brány, zatímco IPv6 obvykle používá oznámení routeru místo DHCP, jak popisuje dokumentace AOSP k tetheringu. Třetí je další přístup: hostitelský telefon předává povolený provoz na tu nadřazenou cestu, kterou si vybral, což může, ale nemusí být jeho tunel.
Text na klientu vám řekne fázi. Uvíznutí na získávání adresy je druhá fáze, než vůbec nějaký paket odejde do internetu. Připojeno, s adresou, ale nic se nenačítá je třetí fáze, kde záleží na směrování, jménech i pokrytí tunelu. Diagnostikovat třetí fázi, když klient uvízl ve druhé, je způsob, jak z pětiminutového problému s leasingem je odpoledne úprav DNS.
Mýtus: směrovaná VPN mění místní DHCP na vzdálený požadavek
Směrovaný tunel přenáší IP pakety pro cíle, které si vybere. DHCP discover je vysílání ve vlastním segmentu hotspotu a tetheringová služba v telefonu na něj odpovídá lokálně, proto klient může dostat adresu, i když tunel běží. Jen záměrně přemostěné nebo relayové řešení posílá tuto výměnu jinam, a to je jiné uspořádání s jiným podpisem selhání.
Takže „server VPN neodpovídá na DHCP“ není diagnóza, je to chyba modelu. Místní zprostředkovatel je v telefonu. Pokud přestane odpovídat, důvody jsou místní: tetheringová služba, limit klientů, fond leasingů nebo klient, který nikdy pořádně nedokončil přidružení. Nic z toho nežije na vzdálené straně tunelu.
Co vlastně dokazuje fungující stávající klient
Pokud laptop, který už byl připojen, stále funguje, zatímco nový telefon ne, hotspot i nadřazená cesta jsou zhruba živé. To srovnání je užitečné a není důkazem, která součást je vinna, protože fungující klient může prostě držet leasing z doby před změnou a tiše ho obnovovat.
Stojí za to zkontrolovat dva místní limity, dokud jste tam. Hotspot obsluhuje konečný fond leasingů a nastavitelný limit klientů, takže zařízení, které se připojilo a usnulo, může držet adresu, zatímco nové čeká. A klient, který si pamatuje statickou konfiguraci z jiné sítě, o leasing vůbec nepožádá, což zvenčí vypadá stejně a opravuje se na klientu, ne v telefonu.
Držte srovnání místní a vratné
Na zařízení, kde to zásady dovolují, porovnejte jedno připojení nového klienta s tunelem neaktivním a poté aktivním, přičemž hotspot a klient zůstanou jinak beze změny. Zaznamenejte verze telefonu a klienta, zvolený profil a přesnou fázi, která selhala. Na spravovaném telefonu si vyžádejte schválené srovnání místo vypnutí vymáhání, abyste získali čistší test.
Konzistentní selhání leasingu závislé na tunelu je užitečný důkaz o místní politice nebo interakci implementací. Není to licence vyčistit každé pravidlo předávání a NAT v zařízení. Ta pravidla chrání nesouvisející provoz a široké povolení předávání nevysvětluje, proč místní služba DHCP přestala odpovídat.
Chybějící leasing nepřelepujte odhadnutou statickou adresou. Záměrná statická konfigurace potřebuje skutečnou podsíť, bránu, alokační plán a kontrolu kolizí. Změna DNS klienta nic z toho nedodá a další zařízení nechá se stejnou závadou.
Co leasing neprokazuje
Získání adresy dokazuje přijetí do místní sítě, ne ochranu tunelem telefonu. Jakmile má klient leasing, vyhodnoťte cestu dolů samostatně: prochází provoz klienta skutečně telefonem, rozkládají se dotazy tam, kde očekáváte, a odpovídá vnější adresa zamýšlenému výstupu? To jsou otázky třetí fáze a zaslouží si vlastní test, místo aby se vkládaly do připojení.
Projděte fáze popořadě a selhání přestane cestovat. Klient uvízlý na získávání adresy je místní otázka tetheringu; klient s adresou a bez stránek je otázka předávání nebo jmen; klient se stránkami a špatným výstupem je otázka pokrytí tunelu. Držet je oddělené je většina ladění.