Naujas hotspot klientas, užstrigęs ties IP gavimu, nėra VPN gedimas
Susijungimas, vietinė DHCP nuoma ir tolesnis perdavimas yra trys etapai. Įrenginys, užstrigęs ties adreso gavimu, niekada nepasiekė VPN, todėl nustokite redaguoti DNS.
Telefonas prisijungia prie hotspot, lieka ties „Gaunamas IP adresas“ ir galiausiai pasiduoda. Natūrali išvada — telefono VPN trukdo DNS, todėl žmonės pradeda redaguoti resolverius ir pridėtas taisykles. Tai netinkamas etapas. Klientas niekada negavo vietinio adreso, o be jo neturi nei tinklų sietuvo, nei resolverio, nei ko perduoti, todėl jokia VPN nuostata pagrindiniame telefone negali paaiškinti šio gedimo. Susijungimas, vietinio adreso priskyrimas ir tolesnis perdavimas yra trys atskiri etapai, ir tik paskutinis susijęs su tuneliu.
Trys etapai ir kuriame esate
Pirmiausia ateina susijungimas: klientas prisijungia prie hotspot belaidžio tinklo. Neteisingas slaptažodis, WPA3 nesuderinamumas ar radijo suderinamumo problema čia nepavyksta, ir klientas paprastai tai pasako. Antra — adreso priskyrimas: IPv4 atveju klientas prašo nuomos ir gauna adresą bei vietines tinklų sietuvo nuostatas, o IPv6 paprastai naudoja maršrutizatoriaus skelbimus vietoje DHCP, kaip aprašo AOSP tethering dokumentacija. Trečia — išėjimas į išorę: pagrindinis telefonas perduoda leistiną srautą į pasirinktą aukštupio kelią, kuris gali būti jo tunelis arba ne.
Užrašas kliente nurodo etapą. Užstrigimas ties adreso gavimu yra antrasis etapas, prieš bet kuriam paketui iškeliaujant į internetą. Prisijungta, adresas yra, bet niekas nesikrauna — trečiasis etapas, kuriame svarbu maršrutizavimas, vardai ir tunelio aprėptis. Diagnozuoti trečiąjį etapą, kai klientas užstrigęs antrajame, yra būdas penkių minučių nuomos problemą paversti DNS redagavimo popiete.
Mitas: maršrutizuotas VPN paverčia vietinį DHCP nuotoline užklausa
Maršrutizuotas tunelis perkelia IP paketus tiems tikslams, kuriuos pasirenka. DHCP aptikimas yra transliacija pačiame hotspot segmente, o telefone esanti tethering paslauga į jį atsako vietoje, todėl klientas gali gauti adresą, kai tunelis įjungtas. Tik sąmoningai sujungtas arba perduotas sprendimas siunčia tą mainus kitur, ir tai kita konfigūracija su kitu gedimo parašu.
Taigi „VPN serveris neatsako į DHCP“ nėra diagnozė, tai modelio klaida. Vietinis tarpininkas yra telefone. Jei jis nustoja atsakinėti, priežastys yra vietinės: tethering paslauga, klientų limitas, nuomos baseinas arba klientas, kuris niekada tinkamai neužbaigė susijungimo. Nė viena iš jų neegzistuoja tolimoje tunelio pusėje.
Ką iš tikrųjų įrodo veikiantis esamas klientas
Jei nešiojamasis kompiuteris, kuris jau buvo prisijungęs, vis dar veikia, o naujas telefonas ne, hotspot ir aukštupio kelias apskritai gyvi. Šis palyginimas naudingas ir jis nėra įrodymas, kuri sudedamoji kalta, nes veikiantis klientas gali tiesiog laikyti nuomą iš prieš pakeitimą ir tyliai ją atnaujinti.
Verta patikrinti dvi vietines ribas, kol esate ten. Hotspot serveris teikia baigtinį nuomos baseiną ir konfigūruojamą klientų limitą, todėl įrenginys, kuris prisijungė ir užmigo, gali laikyti adresą, kol naujas laukia. Ir klientas, kuris prisimena statinę konfigūraciją iš kito tinklo, nuomos visai neprašys, o tai iš išorės atrodo identiškai ir taisoma kliente, ne telefone.
Laikykite palyginimą vietinį ir grįžtamą
Įrenginyje, kur politika leidžia, palyginkite vieną naujo kliento prisijungimą su tuneliu išjungtu, o paskui įjungtu, palikdami hotspot ir klientą kitu atžvilgiu nepakeistus. Užrašykite telefono ir kliento versijas, pasirinktą profilį ir tikslų etapą, kuris nepavyko. Valdomame telefone paprašykite patvirtinto palyginimo, o ne išjungkite vykdymą, kad testas būtų švaresnis.
Nuoseklus nuo tunelio priklausantis nuomos gedimas yra naudingas įrodymas apie vietinę politiką ar įgyvendinimo sąveiką. Tai nėra licencija išvalyti kiekvieną perdavimo ir NAT taisyklę įrenginyje. Tos taisyklės saugo nesusijusį srautą, o platus perdavimo leidimas nepaaiškina, kodėl vietinė DHCP paslauga nustojo atsakinėti.
Neuždėkite trūkstamos nuomos spėjamu statiniu adresu. Sąmoningai statinei konfigūracijai reikia tikrojo potinklio, tinklų sietuvo, paskirstymo plano ir susidūrimų patikros. Kliento DNS pakeitimas nieko iš to neduoda ir palieka kitą įrenginį su tuo pačiu gedimu.
Ko nuoma neįrodo
Adreso gavimas įrodo patekimą į vietinį tinklą, o ne apsaugą telefono tuneliu. Kai klientas turi nuomą, įvertinkite pasroviui kelią atskirai: ar kliento srautas tikrai eina per telefoną, ar užklausos sprendžiamos ten, kur tikitės, ir ar išorinis adresas atitinka numatytą išėjimą? Tai trečiojo etapo klausimai, ir jie verti savo testų, o ne sulankstyti į prisijungimą.
Dirbkite etapais iš eilės ir gedimas nustos judėti. Klientas, užstrigęs ties adreso gavimu, yra vietinis tethering klausimas; klientas su adresu ir be puslapių yra perdavimo ar vardų klausimas; klientas su puslapiais ir netinkamu išėjimu yra tunelio aprėpties klausimas. Jų atskyrimas yra didžioji derinimo dalis.