Android VPN razrješava puno ime hosta, ali ne kratko ime

Upišetefilesu emulator terminala i ništa se ne vrati; upišetefiles.corp.examplei isti server odmah odgovori. Ništa se u VPN vjerodajnicama nije promijenilo, a privatni DNS server nikada nije bio pokvaren. Na Androidu kratka oznaka i puno ime idu različitim putevima kroz razrješivač, a jedan od tih puteva zavisi od postavke koju vlasnik tunela mora dostaviti. Odluka pred vama nije koji DNS server promijeniti, nego ko kontroliše mrežu koju aplikacija zapravo koristi.

Domena pretrage nije adresa. To je lista sufiksa koje razrješivač dodaje na golu oznaku prije nego što odustane.

Sufiks pretrage i DNS server su odvojena polja

Adresa razrješivača kaže Androidu gdje da pita. Sufiks pretrage mu kaže šta da traži kada date samo krajnju lijevu oznaku. Oboje žive na istom mrežnom objektu, a bilo koje može nedostajati samo po sebi.

Ta nezavisnost je upravo razlog zašto puno ime hosta radi. Potpuno kvalifikovano ime ne treba sufiks, jer je već niz koji ide serveru.

Android otkriva tu podjelu krozLinkProperties. Lista DNS servera i lista pretrage domena stoje na istom objektu, a druga je redovno prazna čak i kada je prva potpuno popunjena. Mreža s razrješivačem ali bez domene je mreža u kojoj sufiks nikada nije primijenjen — a ne server koji je odbio kratko ime.

Pročitajte efektivnu mrežu prije nego što bilo šta promijenite

Wi-Fi, mobilna mreža i VPN interfejs su tri odvojene mreže, a tunel postaje zadani kada se podigne. Zato sufiks koji je radio na uredskom Wi-Fi-ju nije automatski sufiks na snazi dok je tunel aktivan. Provjerite mrežu na kojoj je aplikacija stvarno odabrana, a ne onu koju ste podesili prošle sedmice.

Terminalna ljuska na uređaju je slab svjedok ovdje, jer njenresolv.confodražava jedan pogled na razrješivač, a ne pogled svake aplikacije.

Adresne trake preglednika dodaju još jedan sloj: gola riječ može biti tretirana kao upit za pretragu ili razriješena krozvlastitu politiku preglednika za šifrirani DNS, pa stranica koja se učita u Chromeu ne dokazuje ništa o sistemskim pretragama. Testirajte nečim što koristi platformski razrješivač i ispisuje šta je vraćeno. Zatim pokrenite kratki i puni oblik u istoj sesiji, na istoj mreži, i zabilježite koji je dao odgovor.

Ako gradite VPN aplikaciju, prikačite sufiks u graditelju

Kada vaša aplikacija uspostavi interfejs krozVpnService,addSearchDomainje podržani ulaz za to. Prima niz domene kao što jecorp.example, i nije alternativni način da se prenese adresa servera.

Poziv vezuje sufiks za mrežu koju gradite, pa nema globalne postavke koju biste poslije preokrenuli. Ako aplikacija razmontira interfejs i ponovo ga izgradi pri ponovnom spajanju, novi graditelj mora ponovo dodati sufiks, inače zamjenska mreža dolazi bez njega.

Ovdje mnogi uvozi desktop profila izgube to polje. Izvoznik upisuje domenu u svoj model, Android frontend mapira samo opcije koje poznaje, a rezultirajući interfejs izgleda ispravno u svakom drugom pogledu. Profil koji radi na laptopu i pada na telefonu obično je praznina u mapiranju, a ne problem protokola.

Ako samo koristite VPN, ovo nije vaše da postavljate

Nema izmjene na strani klijenta koja dodaje sufiks, ni globalnog svojstva koje možete promijeniti da ga lažirate. Vrijednost dostavlja onaj koji posjeduje tunel: u profilu upravljanog klijenta, u njegovom mapiranju po platformi ili kroz ono što server pošalje. Recite na kojoj ste platformi i koje ime pada, jer se desktop i mobilni frontend razilaze upravo na tom polju.

Ponovni uvoz desktop profila opet ne dokazuje ništa o mobilnom mapiranju.

Tri uslova odlučuju imate li defekt ili očekivano ograničenje. Prvo, tretira li organizacija kratku oznaku uopšte kao podržano ime, ili je to pogodnost koja je ikada radila samo na uredskom Wi-Fi-ju? Drugo, dolazi li neuspjela pretraga iz preglednika, koji može potpuno zaobići sistemski razrješivač? Treće, treba li kratko ime biti dostupno kroz tunel, ili samo s LAN-a? Ako je zadnji odgovor samo LAN, dodavanje sufiksa stvorilo bi ime koje se razrješava izvan ureda i zatim se ne rutira.

Kada je sufiks prisutan, a kratka imena i dalje padaju

Ako lista pretrage domena već prikazujecorp.example, prestanite kriviti sufiks. Provjerite vraća li razrješivač ikakav odgovor za prošireno ime, jer sufiks mijenja samo pitanje koje postavljate. On nikada ne čini server mjerodavnim za zonu koju ne hostuje.

Zatim provjerite rutu. Adresa koja se razrješava ali je tunel ne prenosi pada pri spajanju, što izgleda isto kao neuspjela pretraga u pregledniku koji tiho odustane.

Certifikati zaslužuju poseban spomen. HTTPS validacija koristi ime hosta koje ste stvarno upisali, pa kratko ime koje se ispravno proširi i dalje predstavljafilesu rukovanju. Certifikat izdan zafiles.corp.exampleneće se validirati za njega, a ta greška je ispravno ponašanje, a ne simptom DNS problema s kojim ste počeli.

Šta dalje

Potvrdite podjelu prije nego što bilo šta dirate: puno ime se razrješava, kratko ne, ista aplikacija, ista sesija. Zatim pronađite odabranu mrežu i pročitajte njenu listu pretrage domena uz listu razrješivača. Koja god od dvije bude prazna, kaže vam ko mora djelovati — vi, ako posjedujete aplikaciju; operater tunela, ako ne.

Na kraju, dajte prednost punom imenu servisa u oznakama i klijentskoj konfiguraciji gdje je prenosivost važna. Ono preživljava promjenu mreže, ne zavisi od mapiranja koje mobilni frontend možda ne implementira i poklapa se s imenom za koje je certifikat izdan.