VPN v Androide preloží celé meno hostiteľa, ale nie krátke

Zadátefilesdo emulátora terminála a nič sa nevráti; zadátefiles.corp.examplea ten istý server odpovie okamžite. V prihlasovacích údajoch VPN sa nič nezmenilo a súkromný DNS server nebol nikdy pokazený. V Androide idú krátky názov a celé meno rôznymi cestami cez resolver a jedna z tých ciest závisí od nastavenia, ktoré musí dodať vlastník tunela. Rozhodnutie pred vami nie je, ktorý DNS server zmeniť, ale kto ovláda sieť, ktorú aplikácia skutočne používa.

Vyhľadávacia doména nie je adresa. Je to zoznam prípon, ktoré resolver pridá k holému názvu, kým sa vzdá.

Vyhľadávacia prípona a DNS server sú oddelené polia

Adresa resolvera hovorí Androidu, kde sa pýtať. Vyhľadávacia prípona hovorí, na čo sa pýtať, keď zadáte len najľavejší názov. Obe sídlia na tom istom sieťovom objekte a každá môže chýbať samostatne.

Práve táto nezávislosť vysvetľuje, prečo celé meno hostiteľa funguje. Plne kvalifikované meno nepotrebuje príponu, pretože už je to reťazec, ktorý ide na server.

Android toto rozdelenie odhaľuje cezLinkProperties. Zoznam DNS serverov a zoznam vyhľadávania domén sedia na tom istom objekte a druhý je zvyčajne prázdny, aj keď je prvý plne vyplnený. Sieť s resolverom, ale bez domény, je sieť, v ktorej sa prípona nikdy neuplatnila — nie server, ktorý odmietol krátke meno.

Prečítajte si efektívnu sieť, skôr než čokoľvek zmeníte

Wi-Fi, mobilná sieť a rozhranie VPN sú tri oddelené siete a tunel sa po spustení stane predvoleným. Prípona, ktorá fungovala v kancelárskej Wi-Fi, teda nie je automaticky príponou platnou, kým je tunel aktívny. Preskúmajte sieť, na ktorej je aplikácia skutočne vybraná, nie tú, ktorú ste nastavili minulý týždeň.

Terminálový shell na zariadení je tu slabým svedkom, pretože jehoresolv.confodráža jeden pohľad na resolver a nie pohľad každej aplikácie.

Riadky adries prehliadačov pridávajú ďalšiu vrstvu: holé slovo môže byť považované za vyhľadávací dotaz alebo preložené cezvlastnú politiku prehliadača pre šifrované DNS, takže stránka načítaná v Chrome nič nedokazuje o systémovom preklade. Testujte niečím, čo používa resolver platformy a vypíše, čo sa vrátilo. Potom spustite krátku a plnú formu v tej istej relácii, v tej istej sieti, a poznamenajte, ktorá dala odpoveď.

Ak aplikáciu VPN vyvíjate, pripojte príponu v builderi

Keď vaša aplikácia vytvára rozhranie cezVpnService,addSearchDomainje na to podporovaný vstup. Prijíma reťazec domény, napríkladcorp.example, a nie je to alternatívny spôsob, ako odovzdať adresu servera.

Volanie viaže príponu na sieť, ktorú zostavujete, takže neexistuje žiadne globálne nastavenie, ktoré by ste potom prepnuli. Ak aplikácia rozhranie zbúra a pri opätovnom pripojení ho znova zostaví, nový builder musí príponu pridať znova, inak náhradná sieť vznikne bez nej.

Tu mnohé importy desktopových profilov toto pole strácajú. Exportér zapíše doménu do svojho modelu, frontend Androidu namapuje len možnosti, ktoré pozná, a výsledné rozhranie vyzerá vo všetkých ostatných ohľadoch správne. Profil, ktorý funguje na notebooku a zlyhá na telefóne, je zvyčajne medzera v mapovaní, nie problém protokolu.

Ak VPN len používate, toto nie je vaše nastavenie

Neexistuje klientská úprava, ktorá by pridala príponu, ani globálna vlastnosť, ktorú by ste zmenili, aby ste ju predstierali. Hodnotu dodáva ten, kto vlastní tunel: v profile spravovaného klienta, v jeho mapovaní podľa platforiem alebo cez to, čo posiela server. Povedzte, na akej platforme ste a ktoré meno zlyháva, pretože desktopový a mobilný frontend sa rozchádzajú práve v tomto poli.

Opätovný import desktopového profilu opäť nič nedokazuje o mobilnom mapovaní.

Tri podmienky rozhodujú, či máte chybu, alebo očakávané obmedzenie. Po prvé, považuje organizácia krátky názov vôbec za podporované meno, alebo je to pohodlie, ktoré kedysi fungovalo len v kancelárskej Wi-Fi? Po druhé, prichádza zlyhávajúci preklad z prehliadača, ktorý môže systémový resolver úplne obísť? Po tretie, má byť krátke meno dostupné cez tunel, alebo len z LAN? Ak je posledná odpoveď len-LAN, pridanie prípony by vytvorilo meno, ktoré sa preloží mimo kancelárie a potom sa neroutuje.

Keď je prípona prítomná a krátke mená napriek tomu zlyhávajú

Ak zoznam vyhľadávania domén už zobrazujecorp.example, prestaňte viniť príponu. Skontrolujte, či resolver vôbec vracia odpoveď pre rozšírené meno, pretože prípona mení len otázku, ktorú kladiete. Nikdy neurobí server autoritatívnym pre zónu, ktorú nehostuje.

Potom skontrolujte trasu. Adresa, ktorá sa preloží, ale tunel ju nenesie, zlyhá pri pripojení, čo vyzerá rovnako ako zlyhaný preklad v prehliadači, ktorý ticho rezignuje.

Certifikáty si zaslúžia vlastnú zmienku. Validácia HTTPS používa meno hostiteľa, ktoré ste skutočne zadali, takže krátke meno, ktoré sa správne rozšíri, v handshake predsa len predstavujefiles. Certifikát vydaný prefiles.corp.examplepreň nebude platný, a tá chyba je správne správanie, nie príznak problému s DNS, s ktorým ste začali.

Čo robiť ďalej

Potvrďte rozdelenie, skôr než sa čohokoľvek dotknete: celé meno sa preloží, krátke nie, tá istá aplikácia, tá istá relácia. Potom nájdite vybranú sieť a prečítajte jej zoznam vyhľadávania domén vedľa zoznamu resolverov. Ktorý z tých dvoch je prázdny, vám povie, kto musí konať — vy, ak aplikáciu vlastníte; prevádzkovateľ tunela, ak nie.

Na záver uprednostňujte plné meno služby v záložkách a konfigurácii klienta všade, kde záleží na prenositeľnosti. Prežije zmenu siete, nezávisí od mapovania, ktoré mobilný frontend možno neimplementuje, a zodpovedá menu, pre ktoré bol certifikát vydaný.