OpenVPN työntää DNS:n, mutta resolverisi ei ehkä koskaan näe sitä

Asiakasloki näyttää työnnetyn DNS-palvelimen, tunneli on yhdistetty, eikä sisäinen nimi silti ratkea. Itse työnnössä ei ole mitään rikki. Asetus saapui, eikä käyttöjärjestelmän resolveri koskaan käyttänyt sitä, koska useimmissa Unix-asiakkaissa OpenVPN toimittaa arvon ja jättää sovelluksen alustan vastuulle.

Oire: loki näyttää DNS:n ja nimet epäonnistuvat edelleen

OpenVPN dhcp-option välittää DNS- ja toimialatietoja, ja asiakas kirjaa vastaanottamansa. Joissakin toteutuksissa asiakas soveltaa näitä asetuksia sisäisesti; toisissa se vie ne integraatioskriptille tai verkkopalvelulle. Lokirivi kuvaa vain tarinan ensimmäisen puoliskon. Toinen puolisko tapahtuu jossain, mitä asiakas ei hallitse. Siellä vika yleensä asuu.

Siksi yhdistetty tunneli ja epäonnistuva sisäinen nimi esiintyvät niin usein yhdessä. Arvo on läsnä, kuluttaja puuttuu tai on väärin määritetty, ja resolveri käyttää hiljaa edelleen julkista palvelinta, jota se käytti ennen yhteyttä.

Vastaanotettu ei ole sovellettu

Asiakas voi kirjata työnnetyn DNS-arvon, kun järjestelmän resolveri on edelleen toisen palvelun omistuksessa. Selaimella voi myös olla oma salatun DNS:n käytäntönsä, joka ohittaa järjestelmän resolverin kokonaan, mikä synnyttää mieleenpainuvan tilanteen, jossa yksi sovellus ratkaisee sisäisiä nimiä ja toinen ei.

Tarkista toteutuksen tuettu integraatio sen sijaan, että olettaisit jokaisen Unix-asiakkaan kirjoittavan saman tiedoston uudelleen. Tämä oletus on syy siihen, miksi ihmiset muokkaavat resolverin asetuksia, joita mikään ei lue.

Etsi resolverin omistaja alustakohtaisesti

Windowsissa nimenratkaisukäytännön taulukko voi ohjata tietyt liitteet tietyille palvelimille, ja VPN-asiakas voi asentaa sinne sääntöjä. Tarkista käytäntö, älä vain sovittimen DNS-luetteloa. Linuxissa asetusten omistaja voi olla NetworkManager tai systemd-resolved, ja se kumpi omistaa ne, määrää mitä uudelleenyhdistäminen säilyttää.

Lue tehokas tila työkalulla, joka todella vastaa kyselyihin: resolvectl query internal.example.net systemd-resolved-isännässä tai alustan vastaava. Vertaa sitten tätä vastausta DNS-palvelimeen, jonka asiakasloki väittää työntäneensä.

Vältä useiden palveluiden ajamista, jotka kirjoittavat resolverin asetukset yli ilman koordinointia. Kaksi omistajaa tuottaa tuloksen, joka näyttää ajoittaiselta, ja jokainen uudelleenyhdistäminen näyttää korjaavan tai rikkovan sen satunnaisesti.

Skriptit ja foreign_option

OpenVPN vie työnnetyt asetukset skripteille foreign_option_N-nimisillä muuttujilla, ja skripti voi kääntää ne resolverin komennoiksi. Tämä järjestely on tuettu integraatio, ei automaattinen käyttäytyminen, ja se on asennettava ja kutsuttava asiakkaassa.

Jos nojaat skriptiin, kirjaa sen suoritus ja poistumistila. Skripti, joka toimii mutta epäonnistuu hiljaa, jättää saman oireen kuin ei skriptiä lainkaan, ja se on vaikeampi huomata, koska asetukset näyttävät täydellisiltä. Tarkista skriptin tuloste, ei skriptitiedostoa. Olemassa oleva tiedosto ei ole skripti, joka suoritettiin.

Testaa nimeä, älä lokia

Kysy asiakkaalta vain sisäistä isäntänimeä yhteyden jälkeen, kysy sitten julkinen nimi ja tarkista sitten, mikä palvelin vastasi. Toimivassa kokoonpanossa kaksi vastausta tulevat eri paikoista, ja molempien pitäisi vastata suunnittelua.

Jos nimi ratkeaa mutta palvelu epäonnistuu, siirry reititykseen ja sovellusten käyttöön sen sijaan että muuttaisit DNS:ää uudelleen. OpenVPN:n käsikirja dokumentoi dhcp-optionin ja skriptiympäristön; käytä sitä vahvistaaksesi, mitä asiakkaasi odotetaan soveltavan, ennen kuin muokkaat vielä yhtä resolveritiedostoa.