Android-VPN solvas la plenan hostnomon sed ne la mallongan

Vi tajpasfilesen terminalan emulilon kaj nenio revenas; vi tajpasfiles.corp.examplekaj la sama servilo tuj respondas. Nenio ŝanĝiĝis en la VPN-akreditaĵoj, kaj la privata DNS-servilo neniam difektiĝis. En Android la mallonga etikedo kaj la plena nomo iras malsamajn vojojn tra la solvilo, kaj unu el tiuj vojoj dependas de agordo, kiun la posedanto de la tunelo devas provizi. La decido antaŭ vi ne estas kiun DNS-servilon ŝanĝi, sed kiu regas la reton, kiun la apo efektive uzas.

Serĉdomajno ne estas adreso. Ĝi estas listo de sufiksoj, kiujn la solvilo aldonas al nuda etikedo antaŭ ol rezigni.

Serĉa sufikso kaj DNS-servilo estas apartaj kampoj

La solvila adreso diras al Android kie demandi. La serĉa sufikso diras al ĝi kion demandi, kiam vi donas nur la plej maldekstran etikedon. Ambaŭ loĝas sur la sama retobjekto, kaj ĉiu povas manki sola.

Ĝuste tiu sendependeco klarigas, kial la plena hostnomo funkcias. Plene kvalifikita nomo bezonas neniun sufikson, ĉar ĝi jam estas la ĉeno, kiu iras al la servilo.

Android montras tiun disigon perLinkProperties. La listo de DNS-serviloj kaj la domajna serĉlisto sidas sur la sama objekto, kaj la dua estas kutime malplena eĉ kiam la unua estas plene plenigita. Reto kun solvilo sed sen domajno estas reto, en kiu la sufikso neniam estis aplikita — ne servilo, kiu rifuzis la mallongan nomon.

Legi la efikan reton antaŭ ol ŝanĝi ion

Wi-Fi, poŝtelefona reto kaj VPN-interfaco estas tri apartaj retoj, kaj la tunelo fariĝas la defaŭlta tuj kiam ĝi ekfunkcias. La sufikso, kiu funkciis en la oficeja Wi-Fi, do ne aŭtomate estas la sufikso valida dum la tunelo aktivas. Kontrolu la reton, sur kiu la apo efektive elektiĝas, ne tiun, kiun vi agordis pasintsemajne.

Terminala ŝelo sur la aparato estas mallonga atestanto ĉi tie, ĉar ĝiaresolv.confreflektas unu vidpunkton de la solvilo, ne tiun de ĉiu apo.

Adresbretoj de retumiloj aldonas plian tavolon: nuda vorto povas esti traktata kiel serĉdemando aŭ solvata perla propra politiko de la retumilo pri ĉifrita DNS, do paĝo ŝarĝanta en Chrome pruvas nenion pri sistemaj serĉoj. Testu per io, kio uzas la platforman solvilon kaj presas, kio revenis. Poste rulu la mallongan kaj la plenan formon en la sama seanco, en la sama reto, kaj notu, kiu produktis respondon.

Se vi konstruas la VPN-apon, aldonu la sufikson en la konstruilo

Kiam via apo starigas la interfacon perVpnService,addSearchDomainestas la subtenata enigo por tio. Ĝi prenas domajnan ĉenon kielcorp.example, kaj ĝi ne estas alternativa maniero transdoni servilan adreson.

La voko ligas la sufikson al la reto, kiun vi konstruas, do ne ekzistas tutmonda agordo por renversi poste. Se la apo malkonstruas la interfacon kaj rekonstruas ĝin ĉe rekonekto, la nova konstruilo devas aldoni la sufikson denove, alie la anstataŭa reto ekfunkcias sen ĝi.

Ĉi tie multaj importoj de labortablaj profiloj perdas la kampon. La eksportilo skribas la domajnon en sian propran modelon, la Android-fronto mapas nur la opciojn, kiujn ĝi konas, kaj la rezulta interfaco aspektas ĝusta laŭ ĉiu alia aspekto. Profilo, kiu funkcias sur tekkomputilo kaj malsukcesas sur telefono, kutime estas mapada manko, ne protokola problemo.

Se vi nur uzas la VPN, tio ne estas via agordado

Ne ekzistas klientflanka redakto, kiu aldonas sufikson, nek tutmonda eco, kiun vi povus ŝanĝi por ŝajnigi unu. La valoron liveras tiu, kiu posedas la tunelon: en la profilo de la administrata kliento, en ĝia mapado por platformo, aŭ per tio, kion la servilo sendas. Diru, sur kiu platformo vi estas kaj kiu nomo malsukcesas, ĉar la labortablaj kaj poŝtelefonaj frontoj diverĝas ĝuste en tiu kampo.

Ree importi labortablan profilon denove pruvas nenion pri la poŝtelefona mapado.

Tri kondiĉoj decidas, ĉu vi havas difekton aŭ atendatan limigon. Unue, ĉu la organizo tute traktas la mallongan etikedon kiel subtenatan nomon, aŭ ĉu ĝi estas oportuneco, kiu iam funkciis nur en la oficeja Wi-Fi? Due, ĉu la malsukcesa serĉo venas de retumilo, kiu povas tute preterpasi la sisteman solvilon? Trie, ĉu la mallonga nomo estu atingebla tra la tunelo aŭ nur el la LAN? Se la lasta respondo estas nur-LAN, aldoni sufikson krei nomon, kiu solviĝas ekster la oficejo kaj poste ne enkursiĝas.

Kiam la sufikso ĉeestas kaj mallongaj nomoj ankoraŭ malsukcesas

Se la domajna serĉlisto jam montrascorp.example, ĉesu kulpi la sufikson. Kontrolu, ĉu la solvilo entute redonas respondon por la etendita nomo, ĉar sufikso nur ŝanĝas la demandon, kiun vi faras. Ĝi neniam faras la servilon aŭtoritata por zono, kiun ĝi ne gastigas.

Poste kontrolu la itineron. Adreso, kiu solviĝas sed ne estas portata de la tunelo, malsukcesas ĉe konekto, kio aspektas identa al serĉa malsukceso en retumilo, kiu silente rezignas.

Atestiloj meritas propran mencion. HTTPS-validigo uzas la hostnomon, kiun vi efektive tajpis, do mallonga nomo, kiu ĝuste etendiĝas, ankoraŭ prezentasfilesen la manpremo. Atestilo eldonita porfiles.corp.examplene validiĝos por ĝi, kaj tiu eraro estas ĝusta konduto, ne simptomo de la DNS-problemo, kun kiu vi komencis.

Kion fari poste

Konfirmu la disigon antaŭ ol tuŝi ion: la plena nomo solviĝas, la mallonga ne, sama apo, sama seanco. Poste trovu la elektitan reton kaj legu ĝian domajnan serĉliston apud ĝia solvila listo. Kiu ajn el la du estas malplena, tiu diras al vi, kiu devas agi — vi, se vi posedas la apon; la tunela operacianto, se ne.

Fine, preferu la plenan servan hostnomon en legosignoj kaj klienta agordo, kie porteblo gravas. Ĝi postvivas retŝanĝon, ĝi ne dependas de mapado, kiun la poŝtelefona fronto eble ne realigas, kaj ĝi kongruas kun la nomo, por kiu atestilo estis eldonita.