VPN-ul din Android rezolvă numele de gazdă complet, dar nu numele scurt
Un domeniu de căutare și adresa unui server DNS sunt câmpuri separate în Android. Stabiliți care lipsește înainte de a schimba tunelul sau acreditările.
Tastațifilesîntr-un emulator de terminal și nu se întoarce nimic; tastațifiles.corp.exampleși același server răspunde imediat. Nimic nu s-a schimbat în acreditările VPN, iar serverul DNS privat nu a fost niciodată stricat. În Android, eticheta scurtă și numele complet merg pe căi diferite prin resolver, iar una dintre aceste căi depinde de o setare pe care proprietarul tunelului trebuie să o furnizeze. Decizia din fața dumneavoastră nu este ce server DNS să schimbați, ci cine controlează rețeaua pe care aplicația o folosește de fapt.
Un domeniu de căutare nu este o adresă. Este o listă de sufixe pe care resolverul le adaugă la o etichetă simplă înainte de a renunța.
Un sufix de căutare și un server DNS sunt câmpuri separate
Adresa resolverului îi spune Androidului unde să întrebe. Sufixul de căutare îi spune ce să întrebe atunci când furnizați doar eticheta din stânga. Ambele locuiesc pe același obiect de rețea, iar oricare dintre ele poate lipsi de una singură.
Exact această independență explică de ce funcționează numele de gazdă complet. Un nume complet calificat nu are nevoie de sufix, pentru că este deja șirul care merge la server.
Android expune această separare prinLinkProperties. Lista de servere DNS și lista de căutare a domeniilor stau pe același obiect, iar a doua este adesea goală chiar și atunci când prima este completă. O rețea cu resolver dar fără domeniu este o rețea în care sufixul nu a fost niciodată aplicat — nu un server care a refuzat numele scurt.
Citiți rețeaua efectivă înainte de a schimba ceva
Wi-Fi, rețeaua mobilă și o interfață VPN sunt trei rețele separate, iar tunelul devine implicit de îndată ce urcă. Așadar, sufixul care funcționa în Wi-Fi-ul biroului nu este automat sufixul valabil cât timp tunelul este activ. Inspectați rețeaua pe care aplicația este realmente selectată, nu pe cea pe care ați configurat-o săptămâna trecută.
Un shell de terminal pe dispozitiv este un martor slab aici, pentru căresolv.confsău reflectă o singură viziune a resolverului și nu pe cea a fiecărei aplicații.
Barele de adrese ale browserelor adaugă încă un strat: un cuvânt simplu poate fi tratat ca interogare de căutare sau rezolvat prinpolitica proprie de DNS criptat a browserului, deci o pagină care se încarcă în Chrome nu dovedește nimic despre interogările de sistem. Testați cu ceva care folosește resolverul platformei și afișează ce a revenit. Apoi rulați forma scurtă și forma completă în aceeași sesiune, în aceeași rețea, și notați care a produs un răspuns.
Dacă dezvoltați aplicația VPN, atașați sufixul în constructor
Când aplicația dumneavoastră stabilește interfața prinVpnService,addSearchDomaineste intrarea acceptată pentru aceasta. Primește un șir de domeniu precumcorp.example, și nu este o modalitate alternativă de a transmite o adresă de server.
Apelul leagă sufixul de rețeaua pe care o construiți, deci nu există nicio setare globală de inversat ulterior. Dacă aplicația demontează interfața și o reconstruiește la reconectare, noul constructor trebuie să adauge din nou sufixul, altfel rețeaua de înlocuire urcă fără el.
Aici multe importuri de profiluri desktop pierd câmpul. Exportatorul scrie domeniul în propriul model, frontend-ul Android mapează doar opțiunile pe care le cunoaște, iar interfața rezultată arată corect din toate celelalte puncte de vedere. Un profil care funcționează pe un laptop și eșuează pe un telefon este de obicei o lacună de mapare, nu o problemă de protocol.
Dacă doar consumați VPN-ul, aceasta nu este treaba dumneavoastră să o setați
Nu există nicio editare pe partea clientului care să adauge un sufix și nicio proprietate globală pe care să o schimbați ca să falsificați unul. Valoarea este livrată de cel care deține tunelul: în profilul clientului administrat, în maparea acestuia pe platforme sau prin ceea ce trimite serverul. Spuneți pe ce platformă sunteți și ce nume eșuează, pentru că frontend-urile desktop și mobil diferă exact în acest câmp.
Reimportarea unui profil desktop tot nu dovedește nimic despre maparea mobilă.
Trei condiții decid dacă aveți un defect sau o limitare așteptată. În primul rând, organizația tratează eticheta scurtă ca un nume acceptat, sau este o comoditate care a funcționat vreodată doar în Wi-Fi-ul biroului? În al doilea rând, interogarea care eșuează vine dintr-un browser, care poate ocoli complet resolverul sistemului? În al treilea rând, numele scurt trebuie să fie accesibil prin tunel sau doar din LAN? Dacă ultimul răspuns este doar-LAN, adăugarea unui sufix ar crea un nume care se rezolvă în afara biroului și apoi nu este rutat.
Când sufixul este prezent și numele scurte tot eșuează
Dacă lista de căutare a domeniilor arată dejacorp.example, nu mai dați vina pe sufix. Verificați dacă resolverul returnează vreun răspuns pentru numele extins, pentru că un sufix schimbă doar întrebarea pe care o puneți. Nu face niciodată serverul autoritar pentru o zonă pe care nu o găzduiește.
Apoi verificați ruta. O adresă care se rezolvă dar nu este transportată de tunel eșuează la conectare, ceea ce arată identic cu o interogare eșuată într-un browser care renunță în tăcere.
Certificatele merită o mențiune separată. Validarea HTTPS folosește numele de gazdă pe care l-ați tastat efectiv, deci un nume scurt care se extinde corect prezintă în continuarefilesîn strângerea de mână. Un certificat emis pentrufiles.corp.examplenu va fi valid pentru el, iar acea eroare este un comportament corect, nu un simptom al problemei DNS cu care ați început.
Ce să faceți în continuare
Confirmați separarea înainte de a atinge ceva: numele complet se rezolvă, cel scurt nu, aceeași aplicație, aceeași sesiune. Apoi găsiți rețeaua selectată și citiți lista de căutare a domeniilor alături de lista de resolvere. Oricare dintre cele două este goală vă spune cine trebuie să acționeze — dumneavoastră, dacă dețineți aplicația; operatorul tunelului, dacă nu.
În final, preferați numele complet al serviciului în marcaje și în configurația clientului oriunde contează portabilitatea. Rezistă la o schimbare de rețea, nu depinde de o mapare pe care frontend-ul mobil poate să nu o implementeze și corespunde numelui pentru care a fost emis un certificat.