Android VPN atrisina pilnu resursdatora nosaukumu, bet ne īso nosaukumu
Meklēšanas domēns un DNS servera adrese Android ierīcē ir atsevišķi lauki. Pirms tuneļa vai akreditācijas datu maiņas nosakiet, kura trūkst.
Jūs ierakstātfilestermināla emulatorā un nekas neatgriežas; jūs ierakstātfiles.corp.exampleun tas pats serveris atbild nekavējoties. VPN akreditācijas datos nekas nav mainījies, un privātais DNS serveris nekad nav bijis bojāts. Android ierīcē īsā etiķete un pilnais nosaukums iet pa dažādiem ceļiem caur atrisinātāju, un viens no šiem ceļiem ir atkarīgs no iestatījuma, kas tuneļa īpašniekam ir jānodrošina. Lēmums jūsu priekšā nav par to, kuru DNS serveri mainīt, bet gan par to, kurš kontrolē tīklu, kuru lietotne faktiski izmanto.
Meklēšanas domēns nav adrese. Tas ir sufiksu saraksts, ko atrisinātājs pievieno tukšai etiķetei, pirms padodas.
Meklēšanas sufikss un DNS serveris ir atsevišķi lauki
Atrisinātāja adrese pasaka Android, kur jautāt. Meklēšanas sufikss pasaka, ko jautāt, kad norādāt tikai kreiso etiķeti. Abi dzīvo vienā un tajā pašā tīkla objektā, un jebkurš no tiem var trūkt atsevišķi.
Tieši šī neatkarība izskaidro, kāpēc darbojas pilnais resursdatora nosaukums. Pilnībā kvalificētam nosaukumam nav vajadzīgs sufikss, jo tas jau ir virkne, kas dodas uz serveri.
Android atklāj šo dalījumu caurLinkProperties. DNS serveru saraksts un domēnu meklēšanas saraksts atrodas vienā objektā, un otrais bieži ir tukšs pat tad, ja pirmais ir pilnībā aizpildīts. Tīkls, kurā ir atrisinātājs, bet nav domēna, ir tīkls, kurā sufikss nekad nav piemērots — nevis serveris, kas atteicās no īsā nosaukuma.
Izlasiet faktisko tīklu, pirms kaut ko maināt
Wi-Fi, mobilais tīkls un VPN saskarne ir trīs atsevišķi tīkli, un tunelis kļūst par noklusējumu, tiklīdz tas paceļas. Tāpēc sufikss, kas darbojās biroja Wi-Fi tīklā, nav automātiski tas sufikss, kas ir spēkā, kamēr tunelis ir aktīvs. Pārbaudiet tīklu, kurā lietotne faktiski ir atlasīta, nevis to, kuru konfigurējāt pagājušajā nedēļā.
Termināļa čaula ierīcē šeit ir vājš liecinieks, jo tāsresolv.confatspoguļo vienu atrisinātāja skatījumu, nevis katras lietotnes skatījumu.
Pārlūku adreses joslas pievieno vēl vienu slāni: tukšs vārds var tikt uzskatīts par meklēšanas vaicājumu vai atrisināts, izmantojotpaša pārlūka šifrētā DNS politiku, tāpēc Chrome ielādēta lapa neko nepierāda par sistēmas vaicājumiem. Pārbaudiet ar kaut ko, kas izmanto platformas atrisinātāju un izdrukā, kas atgriezās. Pēc tam palaidiet īso un pilno formu tajā pašā sesijā, tajā pašā tīklā, un atzīmējiet, kura sniedza atbildi.
Ja veidojat VPN lietotni, pievienojiet sufiksu konstruktorā
Kad jūsu lietotne izveido saskarni, izmantojotVpnService,addSearchDomainir tam atbalstītā ievade. Tā pieņem domēna virkni, piemēram,corp.example, un tas nav alternatīvs veids, kā nodot servera adresi.
Izsaukums piesaista sufiksu tīklam, kuru veidojat, tāpēc pēc tam nav globāla iestatījuma, ko apgriezt. Ja lietotne nojauc saskarni un atkārtotas savienošanas laikā to atkal izveido, jaunajam konstruktoram sufikss jāpievieno vēlreiz, citādi aizvietotais tīkls paceļas bez tā.
Šeit daudzi galddatora profilu importi zaudē šo lauku. Eksportētājs ieraksta domēnu savā modelī, Android priekšpuse kartē tikai tās opcijas, ko tā zina, un iegūtā saskarne izskatās pareiza visos citos aspektos. Profils, kas darbojas portatīvajā datorā un neizdodas tālrunī, parasti ir kartēšanas robi, nevis protokola problēma.
Ja jūs tikai lietojat VPN, tas nav jūsu iestatāms
Nav klienta puses rediģējuma, kas pievienotu sufiksu, un nav globāla rekvizīta, ko mainīt, lai to viltojem. Vērtību nodrošina tas, kuram pieder tunelis: pārvaldītā klienta profilā, tā kartējumā pa platformām vai ar to, ko sūta serveris. Pasakiet, kurā platformā esat un kurš nosaukums neizdodas, jo galddatora un mobilās priekšpuses atšķiras tieši šajā laukā.
Galddatora profila atkārtota importēšana atkal neko nepierāda par mobilo kartējumu.
Trīs nosacījumi nosaka, vai jums ir defekts vai sagaidāms ierobežojums. Pirmkārt, vai organizācija vispār uzskata īso etiķeti par atbalstītu nosaukumu, vai tas ir ērtība, kas kādreiz darbojās tikai biroja Wi-Fi tīklā? Otrkārt, vai neveiksmīgais vaicājums nāk no pārlūka, kas var pilnībā apiet sistēmas atrisinātāju? Treškārt, vai īsajam nosaukumam jābūt sasniedzamam caur tuneli, vai tikai no LAN? Ja pēdējā atbilde ir tikai-LAN, sufiksa pievienošana radītu nosaukumu, kas atrisinās ārpus biroja un pēc tam netiek maršrutēts.
Kad sufikss ir, bet īsie nosaukumi joprojām neizdodas
Ja domēnu meklēšanas saraksts jau rādacorp.example, pārtrauciet vainot sufiksu. Pārbaudiet, vai atrisinātājs vispār atgriež atbildi paplašinātajam nosaukumam, jo sufikss maina tikai uzdoto jautājumu. Tas nekad nepadara serveri autoritatīvu zonai, kuru tas nehostē.
Pēc tam pārbaudiet maršrutu. Adrese, kas tiek atrisināta, bet kuru tunelis nenes, neizdodas savienošanās laikā, un tas izskatās identiski neveiksmīgam vaicājumam pārlūkā, kas klusi padodas.
Sertifikāti ir pelnījuši atsevišķu pieminēšanu. HTTPS validācija izmanto resursdatora nosaukumu, ko faktiski ierakstījāt, tāpēc pareizi paplašināts īsais nosaukums roku saspiešanā joprojām uzrādafiles. Sertifikāts, kas izsniegtsfiles.corp.example, šim nosaukumam nebūs derīgs, un šī kļūda ir pareiza uzvedība, nevis sākotnējās DNS problēmas simptoms.
Ko darīt tālāk
Pirms kaut ko aiztikt, apstipriniet dalījumu: pilnais nosaukums atrisinās, īsais ne, tā pati lietotne, tā pati sesija. Pēc tam atrodiet atlasīto tīklu un izlasiet tā domēnu meklēšanas sarakstu līdzās atrisinātāju sarakstam. Kurš no diviem ir tukšs, tas pasaka, kam jārīkojas — jums, ja lietotne ir jūsu; tuneļa operatoram, ja nav.
Visbeidzot, kur svarīga pārvietojamība, grāmatzīmēs un klienta konfigurācijā dodiet priekšroku pilnam pakalpojuma resursdatora nosaukumam. Tas pārdzīvo tīkla maiņu, tas nav atkarīgs no kartējuma, ko mobilā priekšpuse var neīstenot, un tas atbilst nosaukumam, kuram tika izsniegts sertifikāts.