VPN v Androidu přeloží celé jméno hostitele, ale ne krátké

Napíšetefilesdo emulátoru terminálu a nic se nevrátí; napíšetefiles.corp.examplea stejný server okamžitě odpoví. Na přihlašovacích údajích VPN se nic nezměnilo a privátní DNS server nebyl nikdy rozbitý. V Androidu jdou krátký štítek a celé jméno různými cestami přes resolver a jedna z těch cest závisí na nastavení, které musí dodat vlastník tunelu. Rozhodnutí před vámi není, který DNS server změnit, ale kdo ovládá síť, kterou aplikace skutečně používá.

Vyhledávací doména není adresa. Je to seznam přípon, které resolver přidá k holému štítku, než to vzdá.

Vyhledávací přípona a DNS server jsou oddělená pole

Adresa resolveru říká Androidu, kam se ptát. Vyhledávací přípona mu říká, na co se ptát, když zadáte jen nejlevější štítek. Obě žijí na stejném síťovém objektu a každá může chybět sama o sobě.

Právě tato nezávislost vysvětluje, proč celé jméno hostitele funguje. Plně kvalifikované jméno příponu nepotřebuje, protože už je to řetězec, který jde na server.

Android toto rozdělení vystavuje přesLinkProperties. Seznam DNS serverů a seznam vyhledávání domén sedí na stejném objektu a druhý je běžně prázdný, i když první je plně obsazený. Síť s resolverem, ale bez domény, je síť, kde se přípona nikdy neuplatnila — ne server, který odmítl krátké jméno.

Přečtěte si efektivní síť, než cokoli změníte

Wi-Fi, mobilní síť a rozhraní VPN jsou tři oddělené sítě a tunel se po spuštění stane výchozím. Přípona, která fungovala na kancelářské Wi-Fi, tedy není automaticky příponou platnou, dokud je tunel aktivní. Prozkoumejte síť, na které je aplikace skutečně vybraná, ne tu, kterou jste nastavili minulý týden.

Terminálový shell na zařízení je zde slabý svědek, protože jehoresolv.confodráží jeden pohled na resolver, a ne pohled každé aplikace.

Adresní řádky prohlížečů přidávají další vrstvu: holé slovo může být považováno za vyhledávací dotaz nebo přeloženo přesvlastní politiku prohlížeče pro šifrované DNS, takže stránka načtená v Chrome nic nedokazuje o systémovém překladu. Testujte něčím, co používá resolver platformy a vypíše, co se vrátilo. Pak spusťte krátkou a plnou formu ve stejné relaci, na stejné síti, a poznamenejte, která dala odpověď.

Pokud aplikaci VPN vyvíjíte, přiložte příponu v builderu

Když vaše aplikace vytváří rozhraní přesVpnService,addSearchDomainje pro to podporovaný vstup. Bere řetězec domény, napříkladcorp.example, a není to alternativní způsob, jak předat adresu serveru.

Volání váže příponu na síť, kterou sestavujete, takže neexistuje globální nastavení, které byste potom přepnuli. Pokud aplikace rozhraní zboří a při opětovném připojení ho znovu sestaví, nový builder musí příponu přidat znovu, jinak náhradní síť vznikne bez ní.

Zde mnoho importů desktopových profilů toto pole ztrácí. Exportér zapíše doménu do svého modelu, frontend Androidu namapuje jen možnosti, které zná, a výsledné rozhraní vypadá ve všech ostatních ohledech správně. Profil, který funguje na notebooku a selže na telefonu, je obvykle mezera v mapování, ne problém protokolu.

Pokud VPN jen používáte, tohle není vaše nastavení

Neexistuje klientská úprava, která by příponu přidala, ani globální vlastnost, kterou byste změnili, abyste ji předstírali. Hodnotu dodává ten, kdo tunel vlastní: v profilu spravovaného klienta, v jeho mapování pro jednotlivé platformy nebo prostřednictvím toho, co server pošle. Řekněte, na jaké platformě jste a které jméno selhává, protože desktopový a mobilní frontend se rozcházejí právě v tomto poli.

Opětovný import desktopového profilu znovu nic nedokazuje o mobilním mapování.

Tři podmínky rozhodují, zda máte vadu, nebo očekávané omezení. Za prvé, považuje organizace krátký štítek vůbec za podporované jméno, nebo je to pohodlí, které kdy fungovalo jen na kancelářské Wi-Fi? Za druhé, přichází selhávající překlad z prohlížeče, který může systémový resolver úplně obejít? Za třetí, má být krátké jméno dostupné přes tunel, nebo jen z LAN? Pokud je poslední odpověď jen LAN, přidání přípony by vytvořilo jméno, které se přeloží mimo kancelář a pak se neroutuje.

Když je přípona přítomná a krátká jména přesto selhávají

Pokud seznam vyhledávání domén už ukazujecorp.example, přestaňte vinit příponu. Zkontrolujte, zda resolver vůbec vrací odpověď pro rozšířené jméno, protože přípona mění jen otázku, kterou kladete. Nikdy neučiní server autoritativním pro zónu, kterou nehostuje.

Pak zkontrolujte trasu. Adresa, která se přeloží, ale tunel ji nenese, selže při připojení, což vypadá stejně jako selhání překladu v prohlížeči, který tiše rezignuje.

Certifikáty si zaslouží vlastní zmínku. Validace HTTPS používá jméno hostitele, které jste skutečně napsali, takže krátké jméno, které se správně rozšíří, přesto představujefilesv handshake. Certifikát vydaný profiles.corp.examplepro něj nebude validovat, a tato chyba je správné chování, ne symptom problému s DNS, se kterým jste začali.

Co dělat dál

Potvrďte rozdělení, než se čehokoli dotknete: celé jméno se přeloží, krátké ne, stejná aplikace, stejná relace. Pak najděte vybranou síť a přečtěte její seznam vyhledávání domén vedle seznamu resolverů. Který z těch dvou je prázdný, vám řekne, kdo musí jednat — vy, pokud aplikaci vlastníte; provozovatel tunelu, pokud ne.

Nakonec dávejte přednost plnému jménu služby v záložkách a klientské konfiguraci tam, kde záleží na přenositelnosti. Přežije změnu sítě, nezávisí na mapování, které mobilní frontend možná neimplementuje, a odpovídá jménu, pro které byl certifikát vydán.