Android-VPN opløser det fulde værtsnavn, men ikke kortnavnet

Du skriverfilesi en terminalemulator, og der kommer intet tilbage; du skriverfiles.corp.exampleog den samme server svarer med det samme. Der er ikke ændret noget i VPN-loginoplysningerne, og den private DNS-server har aldrig været i stykker. I Android går det korte navn og det fulde navn ad forskellige veje gennem resolveren, og en af de veje afhænger af en indstilling, som ejeren af tunnelen skal levere. Beslutningen foran dig er ikke, hvilken DNS-server du skal skifte, men hvem der styrer det netværk, appen faktisk bruger.

Et søgedomæne er ikke en adresse. Det er en liste af suffikser, som resolveren føjer til et bart navn, før den giver op.

Et søgesuffiks og en DNS-server er to forskellige felter

Resolveradressen fortæller Android, hvor der skal spørges. Søgesuffikset fortæller, hvad der skal spørges om, når du kun angiver det venstreste navn. Begge ligger på det samme netværksobjekt, og hver af dem kan mangle alene.

Netop den uafhængighed er grunden til, at det fulde værtsnavn virker. Et fuldt kvalificeret navn har ikke brug for et suffiks, fordi det allerede er den streng, der sendes til serveren.

Android viser opdelingen gennemLinkProperties. Listen over DNS-servere og listen over domænesøgninger ligger på det samme objekt, og den anden er ofte tom, selv når den første er helt fyldt. Et netværk med en resolver men uden domæne er et netværk, hvor suffikset aldrig blev anvendt — ikke en server, der afviste kortnavnet.

Læs det effektive netværk, før du ændrer noget

Wi-Fi, mobilnet og en VPN-grænseflade er tre separate netværk, og tunnelen bliver standard, så snart den kommer op. Det suffiks, der virkede på kontorets Wi-Fi, er derfor ikke automatisk det suffiks, der gælder, mens tunnelen er aktiv. Undersøg det netværk, appen faktisk er valgt på, ikke det du konfigurerede i sidste uge.

En terminalskal på enheden er et dårligt vidne her, fordi densresolv.confafspejler ét syn på resolveren og ikke hver apps.

Browseres adresselinjer lægger et lag ovenpå: et bart ord kan blive behandlet som en søgeforespørgsel eller opløst gennembrowserens egen politik for krypteret DNS, så en side, der indlæses i Chrome, beviser intet om systemopslag. Test med noget, der bruger platformens resolver og udskriver, hvad der kom tilbage. Kør derefter den korte og den fulde form i samme session, på samme netværk, og noter, hvilken der gav et svar.

Hvis du bygger VPN-appen, skal du vedhæfte suffikset i builderen

Når din app opretter grænsefladen gennemVpnService,addSearchDomainer det den understøttede indgang til dette. Den tager en domænestreng somcorp.example, og den er ikke en alternativ måde at sende en serveradresse på.

Kaldet binder suffikset til det netværk, du bygger, så der er ingen global indstilling at vende bagefter. Hvis appen river grænsefladen ned og genopbygger den ved genopkobling, skal den nye builder tilføje suffikset igen, ellers kommer erstatningsnetværket op uden det.

Det er her, mange importer af skrivebordsprofiler mister feltet. Eksportøren skriver domænet ind i sin egen model, Android-frontenden mapper kun de muligheder, den kender, og den resulterende grænseflade ser korrekt ud i alle andre henseender. En profil, der virker på en bærbar og fejler på en telefon, er som regel et hul i mappingen, ikke et protokolproblem.

Hvis du kun bruger VPN'en, er det ikke dit at sætte

Der er ingen klientredigering, der tilføjer et suffiks, og ingen global egenskab, du kan ændre for at efterligne et. Værdien leveres af den, der ejer tunnelen: i den administrerede klients profil, i dens mapping pr. platform eller gennem det, serveren sender. Sig, hvilken platform du er på, og hvilket navn der fejler, fordi skrivebords- og mobilfrontenderne netop afviger på dette felt.

At importere en skrivebordsprofil igen beviser intet om mobilmappingen.

Tre betingelser afgør, om du har en fejl eller en forventet begrænsning. For det første, behandler organisationen overhovedet kortnavnet som et understøttet navn, eller er det en bekvemmelighed, der kun nogensinde virkede på kontorets Wi-Fi? For det andet, kommer det fejlende opslag fra en browser, som helt kan omgå systemets resolver? For det tredje, skal kortnavnet kunne nås over tunnelen, eller kun fra LAN? Hvis det sidste svar er kun-LAN, ville et suffiks skabe et navn, der opløses uden for kontoret og derefter ikke kan routes.

Når suffikset er der, og kortnavne stadig fejler

Hvis listen over domænesøgninger allerede visercorp.example, så hold op med at give suffikset skylden. Kontroller, om resolveren overhovedet returnerer et svar for det udvidede navn, fordi et suffiks kun ændrer det spørgsmål, du stiller. Det gør aldrig serveren autoritativ for en zone, den ikke hoster.

Kontroller derefter ruten. En adresse, der opløses, men ikke bæres af tunnelen, fejler ved forbindelse, hvilket ser identisk ud med et fejlet opslag i en browser, der giver op i stilhed.

Certifikater fortjener deres egen omtale. HTTPS-validering bruger det værtsnavn, du faktisk skrev, så et kortnavn, der udvides korrekt, præsenterer stadigfilesi håndtrykket. Et certifikat udstedt tilfiles.corp.examplevil ikke validere for det, og den fejl er korrekt adfærd og ikke et symptom på det DNS-problem, du startede med.

Hvad du skal gøre nu

Bekræft opdelingen, før du rører noget: det fulde navn opløses, kortnavnet ikke, samme app, samme session. Find derefter det valgte netværk, og læs dets liste over domænesøgninger sammen med dets resolverliste. Den af de to, der er tom, fortæller dig, hvem der skal handle — dig, hvis du ejer appen; tunnelejeren, hvis du ikke gør.

Foretræk til sidst det fulde tjenesteværtsnavn i bogmærker og klientkonfiguration, hvor portabilitet betyder noget. Det overlever et netværksskift, det afhænger ikke af en mapping, som mobilfrontenden måske ikke implementerer, og det matcher det navn, et certifikat blev udstedt til.