Android VPN išsprendžia visą hosto vardą, bet ne trumpąjį
Paieškos domenas ir DNS serverio adresas Android sistemoje yra atskiri laukai. Nuspręskite, kurio trūksta, prieš keisdami tunelį ar prisijungimo duomenis.
Jūs įvedatefilesį terminalo emuliatorių ir nieko negrįžta; įvedatefiles.corp.exampleir tas pats serveris atsako iš karto. VPN prisijungimo duomenyse niekas nepasikeitė, o privatus DNS serveris niekada nebuvo sugedęs. Android sistemoje trumpa etiketė ir visas vardas eina skirtingais keliais per sprendėją, ir vienas iš tų kelių priklauso nuo nustatymo, kurį turi pateikti tunelio savininkas. Sprendimas prieš jus yra ne kurį DNS serverį keisti, o kas valdo tinklą, kurį programa iš tikrųjų naudoja.
Paieškos domenas nėra adresas. Tai priesagų sąrašas, kurį sprendėjas prideda prie plikos etiketės, prieš pasiduodamas.
Paieškos priesaga ir DNS serveris yra atskiri laukai
Sprendėjo adresas pasako Android, kur klausti. Paieškos priesaga pasako, ko klausti, kai pateikiate tik kairiąją etiketę. Abu gyvena tame pačiame tinklo objekte, ir bet kurio gali trūkti atskirai.
Būtent šis nepriklausomumas paaiškina, kodėl veikia visas hosto vardas. Visiškai kvalifikuotam vardui priesagos nereikia, nes jis jau yra eilutė, kuri eina į serverį.
Android atskleidžia šį atskyrimą perLinkProperties. DNS serverių sąrašas ir domenų paieškos sąrašas yra tame pačiame objekte, ir antrasis dažnai būna tuščias net tada, kai pirmasis pilnai užpildytas. Tinklas, kuriame yra sprendėjas, bet nėra domeno, yra tinklas, kuriame priesaga niekada nebuvo pritaikyta, o ne serveris, kuris atmetė trumpą vardą.
Perskaitykite veiksmingą tinklą, prieš ką nors keisdami
Wi-Fi, mobilusis tinklas ir VPN sąsaja yra trys atskiri tinklai, o tunelis tampa numatytuoju, kai tik pakyla. Todėl priesaga, kuri veikė biuro Wi-Fi tinkle, nėra automatiškai ta priesaga, kuri galioja, kol tunelis aktyvus. Patikrinkite tinklą, kuriame programa iš tikrųjų pasirinkta, o ne tą, kurį nustatėte praėjusią savaitę.
Terminalo apvalkalas įrenginyje čia yra silpnas liudytojas, nes joresolv.confatspindi vieną sprendėjo vaizdą, o ne kiekvienos programos vaizdą.
Naršyklių adreso juostos prideda dar vieną sluoksnį: plikas žodis gali būti traktuojamas kaip paieškos užklausa arba išsprendžiamas perpačios naršyklės užšifruoto DNS politiką, todėl Chrome įkeliamas puslapis nieko neįrodo apie sistemos užklausas. Išbandykite su kuo nors, kas naudoja platformos sprendėją ir išspausdina, kas grįžo. Tada paleiskite trumpąją ir visą formą toje pačioje sesijoje, tame pačiame tinkle, ir pažymėkite, kuri davė atsakymą.
Jei kuriate VPN programą, prisekite priesagą konstruktoriuje
Kai jūsų programa sukuria sąsają perVpnService,addSearchDomainyra tam palaikoma įvestis. Ji priima domeno eilutę, pavyzdžiui,corp.example, ir tai nėra alternatyvus būdas perduoti serverio adresą.
Kvietimas susieja priesagą su tinklu, kurį kuriate, todėl po to nėra jokio globalaus nustatymo, kurį būtų galima apversti. Jei programa išardo sąsają ir perjungiant iš naujo ją atkuria, naujasis konstruktorius turi vėl pridėti priesagą, kitaip pakaitinis tinklas pakyla be jos.
Štai čia daugelis darbalaukio profilių importų praranda šį lauką. Eksportuotojas įrašo domeną į savo modelį, Android priekinė dalis susieja tik tas parinktis, kurias žino, ir gauta sąsaja atrodo teisinga visais kitais atžvilgiais. Profilis, kuris veikia nešiojamajame ir nepavyksta telefone, paprastai yra susiejimo spraga, o ne protokolo problema.
Jei tik naudojatės VPN, tai ne jums nustatyti
Nėra jokio kliento pusės redagavimo, kuris pridėtų priesagą, ir nėra globalios savybės, kurią galėtumėte pakeisti, kad ją suklastotumėte. Vertę pateikia tas, kam priklauso tunelis: valdomo kliento profilyje, jo susiejime pagal platformą arba per tai, ką siunčia serveris. Pasakykite, kurioje platformoje esate ir kuris vardas nepavyksta, nes darbalaukio ir mobiliosios priekinės dalys skiriasi būtent šiame lauke.
Dar kartą importavus darbalaukio profilį, apie mobilųjį susiejimą vėl nieko neįrodoma.
Trys sąlygos nulemia, ar turite defektą, ar tikėtiną apribojimą. Pirma, ar organizacija apskritai laiko trumpą etiketę palaikomu vardu, ar tai patogumas, kuris kada nors veikė tik biuro Wi-Fi tinkle? Antra, ar nepavykstanti užklausa ateina iš naršyklės, kuri gali visiškai apeiti sistemos sprendėją? Trečia, ar trumpasis vardas turi būti pasiekiamas per tunelį, ar tik iš LAN? Jei paskutinis atsakymas yra tik-LAN, priesagos pridėjimas sukurtų vardą, kuris išsprendžiamas už biuro ribų ir tada nėra maršrutizuojamas.
Kai priesaga yra, o trumpieji vardai vis tiek nepavyksta
Jei domenų paieškos sąrašas jau rodocorp.example, nustokite kaltinti priesagą. Patikrinkite, ar sprendėjas apskritai grąžina atsakymą išplėstam vardui, nes priesaga keičia tik užduodamą klausimą. Ji niekada nepadaro serverio įgaliotu zonai, kurios jis nehostina.
Tada patikrinkite maršrutą. Adresas, kuris išsprendžiamas, bet tunelis jo neperduoda, nepavyksta jungiantis, o tai atrodo lygiai taip pat kaip nepavykusi užklausa naršyklėje, kuri tyliai pasiduoda.
Sertifikatai nusipelno atskiro paminėjimo. HTTPS tikrinimas naudoja hosto vardą, kurį iš tikrųjų įvedėte, todėl teisingai išsiplečiantis trumpasis vardas rankos paspaudime vis tiek pateikiafiles. Sertifikatas, išduotas dėlfiles.corp.example, jam nebus galiojantis, ir ta klaida yra teisingas elgesys, o ne jūsų pradinės DNS problemos simptomas.
Ką daryti toliau
Patvirtinkite atskyrimą prieš ką nors liesdami: visas vardas išsprendžiamas, trumpasis ne, ta pati programa, ta pati sesija. Tada suraskite pasirinktą tinklą ir perskaitykite jo domenų paieškos sąrašą šalia sprendėjų sąrašo. Kuris iš dviejų tuščias, tas pasako, kas turi imtis veiksmų — jūs, jei programa jūsų; tunelio operatorius, jei ne.
Galiausiai, kur svarbus perkeliamumas, žymėse ir kliento konfigūracijoje pirmenybę teikite visam paslaugos hosto vardui. Jis išlieka po tinklo pakeitimo, nepriklauso nuo susiejimo, kurio mobilioji priekinė dalis gali neįgyvendinti, ir atitinka vardą, kuriam buvo išduotas sertifikatas.