Az új hotspot-kliens, amely az IP-cím megszerzésénél akad el, nem VPN-hiba

Egy telefon csatlakozik a hotspotthoz, ott marad az „IP-cím megszerzése” ponton, és végül feladja. A természetes következtetés, hogy a telefon VPN-je zavarja a DNS-t, ezért az emberek elkezdik szerkeszteni a feloldókat és a hozzáadott szabályokat. Ez a rossz szakasz. A kliens soha nem kapott helyi címet, és anélkül nincs átjárója, nincs feloldója és nincs mit továbbítania, így semmilyen VPN-beállítás a gazdatelefonon nem magyarázhatja a hibát. A csatlakozás, a helyi címkiosztás és a továbbítás három külön szakasz, és csak az utolsó érinti az alagutat.

A három szakasz, és hogy melyikben van

Először a csatlakozás jön: a kliens csatlakozik a hotspot vezeték nélküli hálózatához. A rossz jelszó, a WPA3-eltérés vagy a rádiókompatibilitási probléma itt bukik el, és a kliens általában ezt is mondja. Másodszor a címkiosztás jön: IPv4 esetén a kliens bérletet kér, és címet plusz helyi átjáróbeállításokat kap, míg az IPv6 általában DHCP helyett útválasztó-hirdetéseket használ, ahogy az AOSP tethering-dokumentációja leírja. Harmadszor a kifelé irányuló hozzáférés jön: a gazdatelefon az engedélyezett forgalmat a választott felső irányú útvonalra továbbítja, amely lehet az alagutja vagy nem.

A kliensen olvasható szöveg megmondja a szakaszt. A cím megszerzésénél elakadás a második szakasz, mielőtt bármely csomag elindulna az internet felé. Csatlakozva, címmel, de semmi sem töltődik be a harmadik szakasz, ahol az útválasztás, a nevek és az alagút lefedettsége mind számít. A harmadik szakasz diagnosztizálása, miközben a kliens a másodikban akad el, az, ahogy egy ötperces bérletproblémából DNS-szerkesztéssel töltött délután lesz.

A mítosz: az útválasztott VPN helyi DHCP-ből távoli kérést csinál

Az útválasztott alagút IP-csomagokat mozgat a kiválasztott célokhoz. A DHCP-felderítés a hotspot saját szegmensén küldött szórás, és a telefonon lévő tethering szolgáltatás helyben válaszol rá, ezért a kliens címet kaphat, miközben az alagút fut. Csak egy szándékosan áthidalt vagy továbbított kialakítás küldi ezt a cserét máshová, és az más elrendezés, más hiba-aláírással.

Tehát „a VPN-kiszolgáló nem válaszol a DHCP-re” nem diagnózis, hanem modellhiba. A helyi közvetítő a telefonon van. Ha felhagy a válaszadással, az okok helyiek: a tethering szolgáltatás, a klienslimit, a bérletkészlet vagy egy kliens, amely soha nem fejezte be rendesen a csatlakozást. Ezek egyike sem él az alagút távoli oldalán.

Mit bizonyít valójában egy működő meglévő kliens

Ha egy már csatlakoztatott laptop továbbra is működik, miközben az új telefon nem, a hotspot és a felső irányú útvonal nagyjából él. Ez az összehasonlítás hasznos, és nem bizonyítja, melyik összetevő a hibás, mert a működő kliens lehet, hogy egyszerűen a változás előtti bérletet tartja, és csendben megújítja.

Két helyi korlátot érdemes ellenőrizni, amíg ott van. A hotspot véges bérletkészletet és beállítható klienslimitet szolgál ki, így egy csatlakozott és elaludt eszköz címet tarthat, miközben egy új vár. És az a kliens, amely egy másik hálózat statikus konfigurációjára emlékszik, egyáltalán nem kér bérletet, ami kívülről azonosnak látszik, és a kliensen javítható, nem a telefonon.

Tartsa az összehasonlítást helyinek és visszafordíthatónak

Egy olyan eszközön, ahol a szabályzat engedi, hasonlítson össze egy új kliens csatlakozást inaktív, majd aktív alagúttal, a hotspotot és a klienst egyébként változatlanul hagyva. Jegyezze fel a telefon és a kliens verzióit, a kiválasztott profilt és a pontos szakaszt, amely elbukott. Kezelt telefonon a jóváhagyott összehasonlítást kérje, ne az érvényesítés kikapcsolását egy tisztább tesztért.

Az alagúttól függő, következetes bérlethiba hasznos bizonyíték a helyi szabályzatról vagy egy megvalósítási kölcsönhatásról. Ez nem engedély arra, hogy az eszköz minden továbbítási és NAT-szabályát törölje. Azok a szabályok független forgalmat védenek, és egy széles továbbítási engedély nem magyarázza meg, miért hagyott fel egy helyi DHCP-szolgáltatás a válaszadással.

Ne fedje el a hiányzó bérletet kitalált statikus címmel sem. A szándékos statikus konfigurációhoz a valódi alhálózat, az átjáró, a kiosztási terv és az ütközésellenőrzés kell. A kliens DNS-ének módosítása ezek egyikét sem adja, és a következő eszközt ugyanazzal a hibával hagyja ott.

Mit nem bizonyít a bérlet

A cím megszerzése a helyi hálózatba való belépést bizonyítja, nem a telefon alagútja általi védelmet. Amint a kliensnek bérlete van, értékelje a lefelé irányuló útvonalat önmagában: a kliens forgalma valóban a telefonon keresztül halad-e, a lekérdezések ott oldódnak-e meg, ahol várja, és a külső cím megegyezik-e a szándékolt kilépéssel? Ezek harmadik szakaszbeli kérdések, és saját tesztet érdemelnek ahelyett, hogy a csatlakozásba hajtogatnánk őket.

Dolgozza fel a szakaszokat sorrendben, és a hiba abbahagyja a vándorlást. A cím megszerzésénél elakadt kliens helyi tethering-kérdés; a címmel rendelkező, de oldalak nélküli kliens továbbítási vagy névkérdés; az oldalakkal rendelkező, de rossz kilépésű kliens alagútlefedettségi kérdés. Ezek szétválasztása a hibakeresés nagy része.