Android-VPN løser opp det fulle vertsnavnet, men ikke kortnavnet

Du skriverfilesi en terminalemulator, og det kommer ingenting tilbake; du skriverfiles.corp.exampleog den samme serveren svarer med en gang. Ingenting er endret i VPN-påloggingsinformasjonen, og den private DNS-serveren har aldri vært ødelagt. I Android går det korte navnet og det fulle navnet ulike veier gjennom resolveren, og én av disse veiene avhenger av en innstilling som eieren av tunnelen må levere. Beslutningen foran deg er ikke hvilken DNS-server du skal bytte, men hvem som kontrollerer nettverket appen faktisk bruker.

Et søkedomene er ikke en adresse. Det er en liste med suffikser som resolveren legger til et bart navn før den gir opp.

Et søkesuffiks og en DNS-server er to separate felt

Resolveradressen forteller Android hvor det skal spørres. Søkesuffikset forteller hva det skal spørres om når du bare oppgir den venstre etiketten. Begge ligger på samme nettobjekt, og hver av dem kan mangle alene.

Nettopp denne uavhengigheten er grunnen til at det fulle vertsnavnet virker. Et fullt kvalifisert navn trenger ikke suffiks, fordi det allerede er strengen som går til serveren.

Android viser denne delingen gjennomLinkProperties. Listen over DNS-servere og listen over domenesøk ligger på samme objekt, og den andre er ofte tom selv når den første er full. Et nettverk med en resolver men uten domene er et nettverk der suffikset aldri ble brukt — ikke en server som avviste kortnavnet.

Les det effektive nettverket før du endrer noe

Wi-Fi, mobilnett og et VPN-grensesnitt er tre separate nettverk, og tunnelen blir standard så snart den kommer opp. Suffikset som virket på kontorets Wi-Fi, er derfor ikke automatisk suffikset som gjelder mens tunnelen er aktiv. Undersøk nettverket appen faktisk er valgt på, ikke det du konfigurerte i forrige uke.

Et terminalskall på enheten er et dårlig vitne her, fordi detsresolv.confgjenspeiler ett syn på resolveren og ikke hver apps syn.

Adresselinjene i nettlesere legger et lag på toppen: et bart ord kan behandles som et søk eller løses vianettleserens egen policy for kryptert DNS, så en side som lastes i Chrome beviser ingenting om systemoppslag. Test med noe som bruker plattformens resolver og skriver ut hva som kom tilbake. Kjør deretter den korte og den fulle formen i samme økt, på samme nettverk, og noter hvilken som ga et svar.

Hvis du bygger VPN-appen, fest suffikset i builderen

Når appen din setter opp grensesnittet gjennomVpnService,addSearchDomainer det den støttede inngangen for dette. Den tar en domenestreng somcorp.example, og den er ikke en alternativ måte å sende en serveradresse på.

Kallet binder suffikset til nettverket du bygger, så det finnes ingen global innstilling å snu etterpå. Hvis appen river grensesnittet ned og bygger det opp igjen ved gjenoppkobling, må den nye builderen legge til suffikset på nytt, ellers kommer erstatningsnettverket opp uten det.

Det er her mange importer av skrivebordsprofiler mister feltet. Eksportøren skriver domenet inn i sin egen modell, Android-frontenden mapper bare alternativene den kjenner, og grensesnittet som kommer ut ser riktig ut på alle andre måter. En profil som virker på en bærbar PC og feiler på en telefon, er vanligvis et hull i mappingen, ikke et protokollproblem.

Hvis du bare bruker VPN-en, er dette ikke ditt å sette

Det finnes ingen klientendring som legger til et suffiks, og ingen global egenskap du kan endre for å late som. Verdien leveres av den som eier tunnelen: i profilen til den administrerte klienten, i dens mapping per plattform, eller gjennom det serveren sender. Si hvilken plattform du er på og hvilket navn som feiler, fordi skrivebords- og mobilfrontendene nettopp skiller lag på dette feltet.

Å importere en skrivebordsprofil på nytt beviser fortsatt ingenting om mobilmappingen.

Tre betingelser avgjør om du har en feil eller en forventet begrensning. For det første, behandler organisasjonen kortnavnet i det hele tatt som et støttet navn, eller er det en bekvemmelighet som bare noen gang virket på kontorets Wi-Fi? For det andre, kommer det mislykkede oppslaget fra en nettleser, som helt kan omgå systemets resolver? For det tredje, skal kortnavnet kunne nås over tunnelen, eller bare fra LAN? Hvis det siste svaret er bare-LAN, vil et suffiks lage et navn som løses utenfor kontoret og deretter ikke rutes.

Når suffikset er der og kortnavnene fortsatt feiler

Hvis listen over domenesøk allerede visercorp.example, slutt å gi suffikset skylden. Sjekk om resolveren i det hele tatt returnerer et svar for det utvidede navnet, fordi et suffiks bare endrer spørsmålet du stiller. Det gjør aldri serveren autoritativ for en sone den ikke hoster.

Sjekk deretter ruten. En adresse som løses opp, men som ikke bæres av tunnelen, feiler ved tilkobling, noe som ser identisk ut med et mislykket oppslag i en nettleser som gir opp i stillhet.

Sertifikater fortjener sin egen omtale. HTTPS-validering bruker vertsnavnet du faktisk skrev, så et kortnavn som utvides riktig, presenterer fortsattfilesi håndtrykket. Et sertifikat utstedt forfiles.corp.examplevil ikke validere for det, og den feilen er korrekt atferd og ikke et symptom på DNS-problemet du startet med.

Hva du bør gjøre nå

Bekreft delingen før du rører noe: det fulle navnet løses opp, kortnavnet ikke, samme app, samme økt. Finn deretter det valgte nettverket og les listen over domenesøk sammen med resolverlisten. Den av de to som er tom, forteller deg hvem som må handle — du, hvis du eier appen; tunneleieren, hvis ikke.

Til slutt bør du foretrekke det fulle tjenestevertsnavnet i bokmerker og klientkonfigurasjon der portabilitet betyr noe. Det overlever et nettverksbytte, det avhenger ikke av en mapping som mobilfrontenden kanskje ikke implementerer, og det samsvarer med navnet et sertifikat ble utstedt for.