Android-VPN løyser opp det fulle vertsnamnet, men ikkje kortnamnet

Du skrivfilesi ein terminalemulator, og det kjem ingenting tilbake; du skrivfiles.corp.exampleog same tenaren svarar med ein gong. Ingenting er endra i VPN-påloggingsinformasjonen, og den private DNS-tenaren har aldri vore øydelagd. I Android går det korte namnet og det fulle namnet ulike vegar gjennom løysaren, og ein av desse vegane er avhengig av ei innstilling som eigaren av tunnelen må levera. Avgjerda framfor deg er ikkje kva DNS-tenar du skal byta, men kven som styrer nettverket appen faktisk brukar.

Eit søkjedomene er ikkje ei adresse. Det er ei liste med suffix som løysaren legg til eit bart namn før han gir opp.

Eit søkjesuffix og ein DNS-tenar er to skilde felt

Løysaradressa fortel Android kvar det skal spørjast. Søkjesuffikset fortel kva det skal spørjast om når du berre oppgir den venstre etiketten. Begge ligg på same nettobjekt, og kvar av dei kan mangla åleine.

Nettopp denne sjølvstendigheita er grunnen til at det fulle vertsnamnet verkar. Eit fullt kvalifisert namn treng ikkje suffix, fordi det allereie er strengen som går til tenaren.

Android viser denne delinga gjennomLinkProperties. Lista over DNS-tenarar og lista over domenesøk ligg på same objekt, og den andre er ofte tom sjølv når den første er full. Eit nettverk med ein løysar men utan domene er eit nettverk der suffikset aldri vart brukt — ikkje ein tenar som avviste kortnamnet.

Les det effektive nettverket før du endrar noko

Wi-Fi, mobilnett og eit VPN-grensesnitt er tre skilde nettverk, og tunnelen blir standard så snart han kjem opp. Suffikset som verka på Wi-Fi-en på kontoret, er derfor ikkje automatisk suffikset som gjeld medan tunnelen er aktiv. Undersøk nettverket appen faktisk er vald på, ikkje det du konfigurerte førre veke.

Eit terminalskal på eininga er eit dårleg vitne her, fordi detresolv.confspeglar eitt syn på løysaren og ikkje synet til kvar app.

Adresselinjer i nettlesarar legg eit lag på toppen: eit bart ord kan handsamast som eit søk eller løysast vianettlesaren sin eigen policy for kryptert DNS, så ei side som lastar i Chrome beviser ingenting om systemoppslag. Test med noko som brukar løysaren til plattforma og skriv ut kva som kom tilbake. Køyr deretter den korte og den fulle forma i same økt, på same nettverk, og noter kva som gav eit svar.

Om du byggjer VPN-appen, fest suffikset i byggjaren

Når appen din set opp grensesnittet gjennomVpnService,addSearchDomainer det den støtta inngangen for dette. Han tek ein domenestreng somcorp.example, og han er ikkje ein alternativ måte å senda ei tenaradresse på.

Kallet bind suffikset til nettverket du byggjer, så det finst inga global innstilling å snu etterpå. Om appen riv grensesnittet ned og byggjer det opp att ved attkopling, må den nye byggjaren leggja til suffikset på nytt, elles kjem erstatningsnettverket opp utan det.

Det er her mange importar av skrivebordsprofilar mistar feltet. Eksportøren skriv domenet inn i sin eigen modell, Android-frontenden mappar berre alternativa han kjenner, og grensesnittet som kjem ut ser rett ut på alle andre måtar. Ein profil som verkar på ein berbar PC og feilar på ein telefon, er vanlegvis eit hol i mappinga, ikkje eit protokollproblem.

Om du berre brukar VPN-en, er dette ikkje ditt å setja

Det finst inga klientendring som legg til eit suffix, og inga global eigenskap du kan endra for å lata som. Verdien blir levert av den som eig tunnelen: i profilen til den styrte klienten, i mappinga hans per plattform, eller gjennom det tenaren sender. Sei kva plattform du er på og kva namn som feilar, fordi skrivebords- og mobilfrontendane nettopp skil lag på dette feltet.

Å importera ein skrivebordsprofil på nytt beviser framleis ingenting om mobilmappinga.

Tre vilkår avgjer om du har ein feil eller ei forventa avgrensing. For det første, handsamar organisasjonen kortnamnet i det heile teke som eit støtta namn, eller er det ei bekvemmelegheit som berre nokon gong verka på Wi-Fi-en på kontoret? For det andre, kjem det mislukka oppslaget frå ein nettlesar, som heilt kan omgå løysaren til systemet? For det tredje, skal kortnamnet kunne nåast over tunnelen, eller berre frå LAN? Om det siste svaret er berre-LAN, vil eit suffix laga eit namn som blir løyst utanfor kontoret og deretter ikkje rutast.

Når suffikset er der og kortnamna framleis feilar

Om lista over domenesøk allereie visercorp.example, slutt å gje suffikset skulda. Sjekk om løysaren i det heile teke returnerer eit svar for det utvida namnet, fordi eit suffix berre endrar spørsmålet du stiller. Det gjer aldri tenaren autoritativ for ei sone han ikkje hostar.

Sjekk deretter ruta. Ei adresse som blir løyst opp, men som ikkje blir boren av tunnelen, feilar ved tilkopling, noko som ser identisk ut med eit mislukka oppslag i ein nettlesar som gir opp i stillheit.

Sertifikat fortener si eiga nemning. HTTPS-validering brukar vertsnamnet du faktisk skreiv, så eit kortnamn som blir utvida rett, presenterer framleisfilesi handtrykket. Eit sertifikat utstedt forfiles.corp.examplevil ikkje validere for det, og den feilen er rett åtferd og ikkje eit symptom på DNS-problemet du starta med.

Kva du bør gjera no

Stadfest delinga før du rører noko: det fulle namnet blir løyst opp, kortnamnet ikkje, same app, same økt. Finn deretter det valde nettverket og les lista over domenesøk saman med løysarlista. Den av dei to som er tom, fortel deg kven som må handle — du, om du eig appen; tunneleigaren, om ikkje.

Til slutt bør du føretrekkja det fulle tenestevertsnamnet i bokmerke og klientkonfigurasjon der portabilitet betyr noko. Det overlever eit nettverksbyte, det er ikkje avhengig av ei mapping som mobilfrontenden kanskje ikkje implementerer, og det samsvarar med namnet eit sertifikat vart utstedt for.