Android-VPN löser det fullständiga värdnamnet men inte kortnamnet

Du skriverfilesi en terminalemulator och ingenting kommer tillbaka; du skriverfiles.corp.exampleoch samma server svarar direkt. Ingenting har ändrats i VPN-inloggningsuppgifterna, och den privata DNS-servern har aldrig varit trasig. I Android går kortnamnet och det fullständiga namnet olika vägar genom resolvern, och en av dessa vägar beror på en inställning som tunnelns ägare måste tillhandahålla. Beslutet framför dig är inte vilken DNS-server du ska byta, utan vem som kontrollerar nätverket som appen faktiskt använder.

En sökdomän är inte en adress. Det är en lista med suffix som resolvern lägger till ett bart namn innan den ger upp.

Ett söksuffix och en DNS-server är två separata fält

Resolveradressen talar om för Android var det ska frågas. Söksuffixet talar om vad det ska frågas efter när du bara anger den vänstra etiketten. Båda bor på samma nätverksobjekt, och var och en kan saknas för sig.

Just detta oberoende är anledningen till att det fullständiga värdnamnet fungerar. Ett fullt kvalificerat namn behöver inget suffix, eftersom det redan är strängen som går till servern.

Android exponerar uppdelningen genomLinkProperties. Listan över DNS-servrar och listan över domänsökningar ligger på samma objekt, och den andra är ofta tom även när den första är full. Ett nätverk med en resolver men utan domän är ett nätverk där suffixet aldrig tillämpades — inte en server som avvisade kortnamnet.

Läs det effektiva nätverket innan du ändrar något

Wi-Fi, mobilnät och ett VPN-gränssnitt är tre separata nätverk, och tunneln blir standard så snart den kommer upp. Suffixet som fungerade i kontorets Wi-Fi är därför inte automatiskt det suffix som gäller medan tunneln är aktiv. Undersök nätverket som appen faktiskt är vald på, inte det du konfigurerade förra veckan.

Ett terminalskal på enheten är ett dåligt vittne här, eftersom dessresolv.confspeglar en syn på resolvern och inte varje apps syn.

Webbläsarnas adressfält lägger till ytterligare ett lager: ett bart ord kan behandlas som en sökfråga eller lösas genomwebbläsarens egen policy för krypterad DNS, så en sida som laddas i Chrome bevisar ingenting om systemets uppslagningar. Testa med något som använder plattformens resolver och skriver ut vad som kom tillbaka. Kör sedan den korta och den fullständiga formen i samma session, på samma nätverk, och notera vilken som gav ett svar.

Om du bygger VPN-appen ska du fästa suffixet i byggaren

När din app sätter upp gränssnittet genomVpnService,addSearchDomainär det den stödda ingången för detta. Den tar en domänsträng somcorp.example, och den är inte ett alternativt sätt att skicka en serveradress.

Anropet binder suffixet till nätverket du bygger, så det finns ingen global inställning att vända efteråt. Om appen river gränssnittet och bygger upp det igen vid återanslutning måste den nya byggaren lägga till suffixet igen, annars kommer ersättningsnätverket upp utan det.

Det är här många importer av skrivbordsprofiler tappar fältet. Exportören skriver domänen i sin egen modell, Android-frontenden mappar bara de alternativ den känner till, och gränssnittet som blir resultatet ser korrekt ut i alla andra avseenden. En profil som fungerar på en bärbar dator och misslyckas i en telefon är vanligtvis en lucka i mappningen, inte ett protokollproblem.

Om du bara använder VPN:n är detta inte ditt att ställa in

Det finns ingen klientändring som lägger till ett suffix, och ingen global egenskap du kan ändra för att fejka ett. Värdet levereras av den som äger tunneln: i den hanterade klientens profil, i dess mappning per plattform, eller genom det servern skickar. Säg vilken plattform du är på och vilket namn som misslyckas, eftersom skrivbords- och mobilfrontenderna skiljer sig just i detta fält.

Att importera en skrivbordsprofil igen bevisar fortfarande ingenting om mobilmappningen.

Tre villkor avgör om du har en defekt eller en förväntad begränsning. För det första, behandlar organisationen kortnamnet överhuvudtaget som ett stött namn, eller är det en bekvämlighet som bara någonsin fungerade i kontorets Wi-Fi? För det andra, kommer den misslyckade uppslagningen från en webbläsare, som helt kan kringgå systemets resolver? För det tredje, ska kortnamnet vara nåbart via tunneln, eller bara från LAN? Om det sista svaret är bara-LAN, skulle ett suffix skapa ett namn som löses utanför kontoret och sedan inte routas.

När suffixet finns och kortnamnen ändå misslyckas

Om listan över domänsökningar redan visarcorp.example, sluta skylla på suffixet. Kontrollera om resolvern överhuvudtaget returnerar ett svar för det utökade namnet, eftersom ett suffix bara ändrar frågan du ställer. Det gör aldrig servern auktoritativ för en zon som den inte hostar.

Kontrollera sedan rutten. En adress som löses men som inte bärs av tunneln misslyckas vid anslutning, vilket ser identiskt ut med ett misslyckat uppslag i en webbläsare som ger upp i tysthet.

Certifikat förtjänar ett eget omnämnande. HTTPS-validering använder det värdnamn du faktiskt skrev, så ett kortnamn som utökas korrekt presenterar fortfarandefilesi handskakningen. Ett certifikat som utfärdats förfiles.corp.examplekommer inte att validera för det, och det felet är korrekt beteende och inte ett symptom på DNS-problemet du började med.

Vad du ska göra härnäst

Bekräfta uppdelningen innan du rör något: det fullständiga namnet löses, kortnamnet inte, samma app, samma session. Hitta sedan det valda nätverket och läs dess lista över domänsökningar vid sidan av resolverlistan. Vilken av de två som är tom talar om för dig vem som måste agera — du, om du äger appen; tunneloperatören, om inte.

Välj slutligen det fullständiga tjänstevärdnamnet i bokmärken och klientkonfiguration där portabilitet spelar roll. Det överlever ett nätverksbyte, det beror inte på en mappning som mobilfrontenden kanske inte implementerar, och det matchar namnet ett certifikat utfärdades för.