Androidi VPN lahendab täisnime, kuid mitte lühinime

Sisestatefilesterminali emulaatorisse ja midagi ei tule tagasi; sisestatefiles.corp.exampleja sama server vastab kohe. VPN-i mandaatides ei ole midagi muutunud ja privaatne DNS-server ei ole kunagi katki olnud. Androidis lähevad lühinimi ja täisnimi lahendaja kaudu erinevaid teid, ja üks neist teedest sõltub seadest, mille peab esitama tunneli omanik. Otsus teie ees ei ole, millist DNS-serverit muuta, vaid kes kontrollib võrku, mida rakendus tegelikult kasutab.

Otsingudomeen ei ole aadress. See on järelliidete loend, mille lahendaja lisab paljale nimele, enne kui alla annab.

Otsingu järelliide ja DNS-server on eraldi väljad

Lahendaja aadress ütleb Androidile, kust küsida. Otsingu järelliide ütleb, mida küsida, kui esitate ainult kõige vasakpoolsema nime. Mõlemad elavad samal võrguobjektil ja kumbki võib iseseisvalt puududa.

Just see sõltumatus selgitab, miks täisnimi töötab. Täielikult kvalifitseeritud nimi ei vaja järelliidet, sest see on juba string, mis serverisse läheb.

Android toob selle jaotuse väljaLinkPropertieskaudu. DNS-serverite loend ja domeeniotsingu loend asuvad samal objektil ning teine on tavaliselt tühi ka siis, kui esimene on täielikult täidetud. Võrk, millel on lahendaja, kuid pole domeeni, on võrk, kus järelliidet ei rakendatud kunagi — mitte server, mis lükkas lühinime tagasi.

Lugege kehtivat võrku, enne kui midagi muudate

Wi-Fi, mobiilivõrk ja VPN-liides on kolm eraldi võrku ning tunnel muutub vaikeväärtuseks kohe, kui see püsti tõuseb. Seega ei ole kontori Wi-Fi-s töötanud järelliide automaatselt järelliide, mis kehtib tunneli aktiivsusel. Uurige võrku, millele rakendus on tegelikult valitud, mitte seda, mille seadistasite eelmisel nädalal.

Seadme terminalikest on siin nõrk tunnistaja, sest selleresolv.confpeegeldab üht vaadet lahendajale, mitte iga rakenduse vaadet.

Brauserite aadressiribad lisavad veel ühe kihi: paljas sõna võidakse käsitleda otsingupäringuna või lahendadabrauseri enda krüpteeritud DNS-i reeglitekaudu, nii et Chrome'is laaditud leht ei tõesta süsteemiotsingute kohta midagi. Testige millegagi, mis kasutab platvormi lahendajat ja trükib välja, mis tagasi tuli. Seejärel käivitage lühike ja täisvorm samas seansis, samas võrgus, ja pange kirja, milline andis vastuse.

Kui ehitate VPN-rakendust, lisage järelliide ehitajas

Kui teie rakendus püstitab liideseVpnServicekaudu,addSearchDomainon selleks toetatud sisend. See võtab domeenistringi, näitekscorp.example, ja see ei ole alternatiivne viis serveri aadressi edastamiseks.

Kutse seob järelliide võrgu külge, mida ehitate, seega ei ole hiljem ümber lülitada ühtegi globaalset seadet. Kui rakendus lammutab liidese ja ehitab selle taasühendamisel uuesti üles, peab uus ehitaja järelliite uuesti lisama, muidu tõuseb asendusvõrk ilma selleta.

Siin kaotavad paljud töölauaprofiilide impordid selle välja. Eksportija kirjutab domeeni oma mudelisse, Androidi esiosa kaardistab ainult need valikud, mida ta teab, ja tulemuseks olev liides näeb kõigis muudes aspektides õige välja. Profiil, mis töötab sülearvutis ja ebaõnnestub telefonis, on tavaliselt kaardistamise lünk, mitte protokolli probleem.

Kui te ainult kasutate VPN-i, ei ole see teie seadistada

Puudub kliendipoolne muudatus, mis lisaks järelliite, ja puudub globaalne omadus, mida saaksite muuta, et seda teeselda. Väärtuse annab see, kellele tunnel kuulub: hallatava kliendi profiilis, selle platvormipõhises kaardistuses või mille kaudu server selle saadab. Öelge, millisel platvormil olete ja milline nimi ebaõnnestub, sest töölaua- ja mobiiliesiosa lähevad just sellel väljal lahku.

Töölauaprofiili uuesti importimine ei tõesta jälle mobiilse kaardistuse kohta midagi.

Kolm tingimust otsustavad, kas teil on defekt või oodatav piirang. Esiteks, kas organisatsioon käsitleb lühinime üldse toetatud nimena või on see mugavus, mis kunagi töötas ainult kontori Wi-Fi-s? Teiseks, kas ebaõnnestuv otsing tuleb brauserist, mis võib süsteemi lahendajast täielikult mööda minna? Kolmandaks, kas lühinimi peaks olema kättesaadav tunneli kaudu või ainult LAN-ist? Kui viimane vastus on ainult LAN, looks järelliite lisamine nime, mis laheneb väljaspool kontorit ja siis ei marsruutu.

Kui järelliide on olemas ja lühinimed ikka ebaõnnestuvad

Kui domeeniotsingu loend juba näitabcorp.example, lõpetage järelliite süüdistamine. Kontrollige, kas lahendaja üldse tagastab vastuse laiendatud nimele, sest järelliide muudab ainult küsimust, mille esitate. See ei tee serverit kunagi autoriteetseks tsooni jaoks, mida see ei hosti.

Seejärel kontrollige marsruuti. Aadress, mis laheneb, kuid mida tunnel ei kanna, ebaõnnestub ühendamisel, mis näeb välja täpselt nagu ebaõnnestunud otsing brauseris, mis vaikselt alla annab.

Sertifikaadid väärivad eraldi mainimist. HTTPS-i valideerimine kasutab hostinime, mille tegelikult sisestasite, nii et õigesti laienduv lühinimi esitab käepigistuses ikkagifiles. Sertifikaat, mis on välja antudfiles.corp.examplejaoks, ei valideeru selle jaoks, ja see viga on õige käitumine, mitte teie alustatud DNS-probleemi sümptom.

Mida edasi teha

Kinnitage jaotus enne, kui millegi puutute: täisnimi laheneb, lühinimi mitte, sama rakendus, sama seanss. Seejärel leidke valitud võrk ja lugege selle domeeniotsingu loendit lahendajate loendi kõrval. Kumb kahest on tühi, see ütleb, kes peab tegutsema — teie, kui rakendus on teie oma; tunneli operaator, kui ei ole.

Lõpuks eelistage täielikku teenuse hostinime järjehoidjates ja kliendi konfiguratsioonis seal, kus teisaldatavus loeb. See elab üle võrguvahetuse, ei sõltu kaardistusest, mida mobiilne esiosa ei pruugi rakendada, ja ühtib nimega, mille jaoks sertifikaat välja anti.