Android-VPN slår opp hele vertsnavnet, men ikke kortnavnet

Du taster files inn i en terminalemulator og får ingenting tilbake; du taster files.corp.example og samme server svarer umiddelbart. Ingenting har endret seg i VPN-påloggingsdetaljene, og den private DNS-serveren har aldri vært i stykker. På Android følger kortnavnet og det fullstendige navnet forskjellige spor gjennom oppslagstjenesten, og ett av sporene avhenger av en innstilling som tunnelens eier må stille med. Valget du står overfor, er ikke hvilken DNS-server du skal bytte, men hvem som råder over nettet appen faktisk bruker.

Et søkedomene er ikke en adresse. Det er en samling endelser som oppslagstjenesten henger på et nakent navn før den gir opp.

Søkeendelse og DNS-server er to atskilte felt

Oppslagstjenestens adresse angir hvor Android skal spørre. Søkeendelsen angir hva den skal spørre om når du bare oppgir den venstre delen. Begge hører til samme nettobjekt, og hver av dem kan mangle for seg selv.

Det er nettopp denne uavhengigheten som gjør at det fullstendige vertsnavnet virker. Et fullt ut kvalifisert navn trenger ingen endelse, siden det allerede er teksten som sendes til serveren.

Android synliggjør denne todelingen gjennom LinkProperties. Oversikten over DNS-servere og oversikten over domenesøk ligger på samme objekt, og den siste er ofte tom selv når den første er helt fylt. Et nett som har oppslagstjeneste men ikke domene, er et nett der endelsen aldri ble tatt i bruk — ikke en server som avviste kortnavnet.

Les det gjeldende nettet før du endrer noe

Wi-Fi, mobilnett og et VPN-grensesnitt er tre atskilte nett, og tunnelen blir standarden straks den er oppe. Endelsen som fungerte på kontorets Wi-Fi, er derfor ikke uten videre den endelsen som gjelder mens tunnelen er i bruk. Gransk nettet appen faktisk er valgt på, ikke det du satte opp forrige uke.

Et terminalskall på enheten er en dårlig kilde her, fordi det resolv.conf gjengir én oppfatning av oppslagstjenesten og ikke oppfatningen til hver enkelt app.

Adressefeltene i nettlesere legger på nok et lag: et nakent ord kan bli behandlet som et søk, eller slått opp gjennom nettleserens egen ordning for kryptert DNS, så en side som lastes i Chrome sier ingenting om systemets oppslag. Prøv med noe som bruker plattformens oppslagstjeneste og skriver ut hva som kom tilbake. Kjør så den korte og den fullstendige formen i samme økt, på samme nett, og noter hvilken som ga svar.

Hvis du lager VPN-appen, må endelsen festes i byggeren

Når appen din reiser grensesnittet gjennom VpnService, addSearchDomain er dette den støttede inngangsverdien. Den tar en domenetekst som corp.example, og den er ikke en annen måte å overføre en serveradresse på.

Kallet knytter endelsen til nettet du bygger, så det finnes ingen global innstilling å vende i etterkant. Hvis appen river ned grensesnittet og reiser det på nytt ved gjenoppkobling, må den nye byggeren legge til endelsen igjen, ellers kommer erstatningsnettet opp uten den.

Det er her mange importerte skrivebordsprofiler mister feltet. Eksportøren skriver domenet inn i sin egen modell, Android-fronten oversetter bare de valgene den kjenner, og grensesnittet som kommer ut, ser riktig ut på alle andre punkter. En profil som virker på en bærbar maskin og svikter på en telefon, er som regel et hull i oversettelsen, ikke et protokollproblem.

Hvis du bare bruker VPN-en, er dette ikke noe du kan stille inn

Det finnes ingen endring på klientsiden som legger til en endelse, og ingen global egenskap du kan justere for å late som. Verdien kommer fra den som eier tunnelen: i profilen til den administrerte klienten, i oversettelsen for hver plattform, eller gjennom det serveren sender. Oppgi hvilken plattform du bruker og hvilket navn som svikter, fordi skrivebords- og mobilfronten nettopp går ulike veier på dette feltet.

Å importere en skrivebordsprofil på nytt beviser fortsatt ingenting om oversettelsen for mobil.

Tre forhold avgjør om du har en feil eller en forventet begrensning. For det første: behandler organisasjonen kortnavnet som et støttet navn i det hele tatt, eller er det en bekvemmelighet som bare har virket på kontorets Wi-Fi? For det andre: kommer det mislykkede oppslaget fra en nettleser, som kan gå helt utenom systemets oppslagstjeneste? For det tredje: skal kortnavnet kunne nås gjennom tunnelen, eller bare fra LAN? Er svaret på det siste bare LAN, vil en endelse lage et navn som slås opp utenfor kontoret og deretter ikke rutes.

Når endelsen finnes og kortnavnene likevel svikter

Hvis oversikten over domenesøk allerede viser corp.example, er det slutt på å skylde på endelsen. Sjekk om oppslagstjenesten i det hele tatt gir svar for det utvidede navnet, fordi en endelse bare endrer spørsmålet du stiller. Den gjør aldri serveren ansvarlig for en sone den ikke har.

Sjekk så ruten. En adresse som slås opp, men som ikke blir fraktet av tunnelen, svikter ved tilkobling, og det ser likt ut som et mislykket oppslag i en nettleser som gir opp uten et ord.

Sertifikater fortjener et eget avsnitt. HTTPS-validering bruker vertsnavnet du faktisk tastet, så et kortnavn som utvides riktig, legger fram files under håndtrykket. Et sertifikat som er utstedt for files.corp.example vil ikke være gyldig for dette, og den feilen er riktig oppførsel og ikke et tegn på DNS-problemet du begynte med.

Hva du gjør videre

Bekreft todelingen før du tar i noe: det fulle navnet slås opp, kortnavnet ikke, samme app, samme økt. Finn så det valgte nettet og les oversikten over domenesøk ved siden av oppslagslisten. Den av de to som er tom, sier deg hvem som må handle — du, hvis du eier appen; den som driver tunnelen, hvis ikke.

Til sist bør du velge det fullstendige tjenestevertsnavnet i bokmerker og klientoppsett der flyttbarhet betyr noe. Det tåler et nettbytte, det er ikke avhengig av en oversettelse som mobilfronten kanskje ikke har, og det stemmer med navnet et sertifikat ble utstedt for.