Androidin VPN ratkaisee täyden isäntänimen mutta ei lyhytnimeä

Kirjoitatfilespääteemulaattoriin eikä mitään tule takaisin; kirjoitatfiles.corp.exampleja sama palvelin vastaa heti. VPN-tunnistetiedoissa ei muuttunut mikään, eikä yksityinen DNS-palvelin ollut koskaan rikki. Androidissa lyhyt nimi ja täysi nimi kulkevat eri reittejä ratkaisijan läpi, ja toinen näistä reiteistä riippuu asetuksesta, jonka tunnelin omistajan on toimitettava. Edessäsi oleva päätös ei ole, mitä DNS-palvelinta vaihtaa, vaan kuka hallitsee verkkoa, jota sovellus todella käyttää.

Hakudomain ei ole osoite. Se on luettelo jälkiliitteistä, jotka ratkaisija lisää paljaaseen nimeen ennen kuin luovuttaa.

Hakuliite ja DNS-palvelin ovat erillisiä kenttiä

Ratkaisijan osoite kertoo Androidille, mistä kysyä. Hakuliite kertoo, mitä kysyä, kun annat vain vasemmanpuoleisimman nimen. Molemmat elävät samassa verkko-objektissa, ja kumpi tahansa voi puuttua yksinään.

Juuri tämä riippumattomuus selittää, miksi täysi isäntänimi toimii. Täysin kvalifioitu nimi ei tarvitse liitettä, koska se on jo merkkijono, joka menee palvelimelle.

Android paljastaa jaonLinkPropertieskautta. DNS-palvelinten luettelo ja verkkotunnushakujen luettelo sijaitsevat samassa objektissa, ja jälkimmäinen on usein tyhjä, vaikka ensimmäinen on täynnä. Verkko, jossa on ratkaisija mutta ei verkkotunnusta, on verkko, jossa liitettä ei koskaan sovellettu — ei palvelin, joka hylkäsi lyhytnimen.

Lue tehollinen verkko ennen kuin muutat mitään

Wi-Fi, mobiiliverkko ja VPN-liittymä ovat kolme erillistä verkkoa, ja tunnelista tulee oletus heti kun se nousee. Siksi toimiston Wi-Fi:ssä toiminut liite ei automaattisesti ole liite, joka on voimassa tunnelin ollessa aktiivinen. Tarkastele verkkoa, jolle sovellus on todella valittu, älä sitä, jonka konfiguroit viime viikolla.

Laitteen päätekomentotulkki on tässä huono todistaja, koska senresolv.confheijastaa yhtä näkemystä ratkaisijasta eikä jokaisen sovelluksen näkemystä.

Selainten osoitepalkit lisäävät vielä yhden kerroksen: paljas sana voidaan tulkita hakukyselyksi tai ratkaistaselaimen oman salatun DNS:n käytännönkautta, joten Chromessa latautuva sivu ei todista mitään järjestelmän hauista. Testaa jollakin, joka käyttää alustan ratkaisijaa ja tulostaa, mitä tuli takaisin. Aja sitten lyhyt ja täysi muoto samassa istunnossa, samassa verkossa, ja merkitse, kumpi tuotti vastauksen.

Jos rakennat VPN-sovellusta, liitä liite rakentajaan

Kun sovelluksesi pystyttää liittymänVpnServicekautta,addSearchDomainon tähän tuettu syöte. Se ottaa verkkotunnusmerkkijonon, esimerkiksicorp.example, eikä se ole vaihtoehtoinen tapa välittää palvelimen osoite.

Kutsu sitoo liitteen verkkoon, jota rakennat, joten jälkeenpäin käännettävää globaalia asetusta ei ole. Jos sovellus purkaa liittymän ja rakentaa sen uudelleen yhteyden palautuessa, uuden rakentajan on lisättävä liite uudelleen, muuten korvaava verkko nousee ilman sitä.

Tässä monet työpöytäprofiilien tuonnit menettävät kentän. Viejä kirjoittaa verkkotunnuksen omaan malliinsa, Androidin käyttöliittymä kuvaa vain ne vaihtoehdot, jotka se tuntee, ja tuloksena oleva liittymä näyttää kaikin muin osin oikealta. Profiili, joka toimii kannettavassa ja epäonnistuu puhelimessa, on yleensä kartoituksen aukko, ei protokollaongelma.

Jos vain käytät VPN:ää, tämä ei ole sinun asetettavasi

Ei ole asiakaspuolen muokkausta, joka lisäisi liitteen, eikä globaalia ominaisuutta, jota voisit muuttaa sen väärentämiseksi. Arvon toimittaa se, joka omistaa tunnelin: hallitun asiakkaan profiilissa, sen alustakohtaisessa kartoituksessa tai sen kautta, mitä palvelin lähettää. Kerro, millä alustalla olet ja mikä nimi epäonnistuu, koska työpöytä- ja mobiilikäyttöliittymät eroavat juuri tässä kentässä.

Työpöytäprofiilin uudelleentuonti ei taas todista mitään mobiilikartoituksesta.

Kolme ehtoa ratkaisee, onko sinulla vika vai odotettu rajoitus. Ensinnäkin, käsitteleekö organisaatio lyhytnimeä ylipäätään tuettuna nimenä vai onko se mukavuus, joka toimi koskaan vain toimiston Wi-Fi:ssä? Toiseksi, tuleeko epäonnistuva haku selaimesta, joka voi ohittaa järjestelmän ratkaisijan kokonaan? Kolmanneksi, pitäisikö lyhytnimen olla saavutettavissa tunnelin kautta vai vain LANista? Jos viimeinen vastaus on vain LAN, liitteen lisääminen loisi nimen, joka ratkeaa toimiston ulkopuolella ja jota sitten ei reititetä.

Kun liite on olemassa ja lyhytnimet silti epäonnistuvat

Jos verkkotunnushakujen luettelo näyttää jocorp.example, lopeta liitteen syyttäminen. Tarkista, palauttaako ratkaisija ylipäätään vastauksen laajennetulle nimelle, koska liite muuttaa vain kysymystä, jonka esität. Se ei koskaan tee palvelimesta valtuutettua vyöhykkeelle, jota se ei isännöi.

Tarkista sitten reitti. Osoite, joka ratkeaa mutta jota tunneli ei kanna, epäonnistuu yhdistettäessä, mikä näyttää samalta kuin epäonnistunut haku selaimessa, joka luovuttaa hiljaa.

Varmenteet ansaitsevat oman maininnan. HTTPS-validointi käyttää isäntänimeä, jonka todella kirjoitit, joten oikein laajeneva lyhytnimi esittää kättelyssä siltifiles. Varmenteen, joka on myönnettyfiles.corp.examplevarten, ei validoidu sille, ja tuo virhe on oikeaa käyttäytymistä eikä merkki aloittamastasi DNS-ongelmasta.

Mitä tehdä seuraavaksi

Vahvista jako ennen kuin kosket mihinkään: täysi nimi ratkeaa, lyhyt ei, sama sovellus, sama istunto. Etsi sitten valittu verkko ja lue sen verkkotunnushakujen luettelo ratkaisijoiden luettelon vierestä. Kumpi tahansa näistä kahdesta on tyhjä, kertoo sinulle, kenen on toimittava — sinä, jos omistat sovelluksen; tunnelin operaattori, jos et.

Lopuksi suosi palvelun täyttä isäntänimeä kirjanmerkeissä ja asiakasasetuksissa siellä, missä siirrettävyys on tärkeää. Se kestää verkon vaihdon, se ei riipu kartoituksesta, jota mobiilikäyttöliittymä ei ehkä toteuta, ja se vastaa nimeä, jolle varmenne myönnettiin.