Sisäiset nimet epäonnistuvat VPN:ssä, julkiset sivustot toimivat

Yksi käyttäjä ilmoittaa, että intranetin isäntänimi ei ratkea VPN:n yli. Toinen raportti samasta kannettavasta sanoo, että vuototesti näyttää yhä kyselyitä, joihin paikallinen resolver vastaa. Ne kuulostavat yhdeltä ongelmalta ja ovat kaksi, eri todistein, ja ensimmäisen tavallinen korjaus pahentaa toista. Erottele ne ennen kuin kosket asetukseen.

Kaksi oiretta, jotka eivät ole yksi vika

Sisäisen nimen ratkaisematta jääminen tarkoittaa, että kysymys meni jonnekin, missä siihen ei ole vastausta. Tunnelista lähtevät kyselyt tarkoittavat, että kysymys meni väärään paikkaan silloinkin kun vastaus oli saatavilla. Ne ovat vastakkaisia vikoja: toisessa vastaus puuttuu, toisessa on ylimääräinen kohde.

Ansio on siinä, että toimiston resolverin lisääminen kaikkialle korjaa ensimmäisen ja takaa toisen. Julkisen resolverin lisääminen kaikkialle tekee päinvastoin.

Kirjaa molemmat havainnot aikaleimalla ja käy sitten alla olevat neljä tarkistusta järjestyksessä läpi.

Minkä sovittimen resolveri saa kysymyksen

Windowsissa DNS-asiakasohjelma valitsee palvelimet sovittimien sidontajärjestyksen mukaan, eikä tunnelisovitin ole automaattisesti ensimmäinen. Avaa sovittimen lisäasetukset ja siirrä etäyhteysyhteys fyysisen sovittimen yläpuolelle, yhdistä sitten uudelleen, jotta muutos astuu voimaan uudessa istunnossa.

Sidontajärjestys on vain ensimmäinen puolisko. Asiakasohjelman on myös tiedettävä, mitkä nimet kuuluvat kyseiselle sovittimelle, ja se on suffiksin eikä järjestyksen kysymys.

Aseta toimivan koneen ipconfig /all tuloste kannettavan tulosteen viereen, molemmat otettu tunnelin ollessa ylhäällä. Toimiva kone näyttää toimistosovittimellaan yhteyskohtaisen DNS-suffiksin, eikä kannettava välttämättä näytä tunnelilla mitään. Tämä ero selittää kokonaisen raporttien luokan, joissa sanotaan palvelimen olevan juuri siinä ja nimen silti epäonnistuvan, koska ilman suffiksia lyhyt nimi ei koskaan täydenny vyöhykkeeksi, jota toimiston resolveri palvelee.

Lyhyt nimi tarvitsee suffiksin ennen kuin reitin

Kvalifioimattoman isäntänimen kirjoittaminen pyytää resolveria arvaamaan verkkotunnuksen. Arvaus tulee yhteyskohtaiseen suffiksiluetteloon ja jos luettelo on tyhjä, kysely lähtee yhtenä tunnisteena, johon mikään yksityinen vyöhyke ei osu.

Kopioi toimivan koneen suffiksi VPN-sovittimen IPv4-ominaisuuksiin DNS-välilehdellä ja yhdistä uudelleen. Linuxissa vastine on tunnelilinkin hakutoimialue, jonka systemd-resolved näyttää linkeittäin eikä maailmanlaajuisesti.

Pidä kaksi asetusta erillään muistiinpanoissasi. Suffiksi muuttaa sitä, mitä kysytään; resolverin osoite muuttaa sitä, keneltä kysytään. Toisen korjaaminen toisen ollessa väärin antaa tuloksen, joka näyttää satunnaiselta.

Kysy resolverilta suoraan, sitten nimeltä

Suora kysely toimiston resolverille erottaa nimiongelman reitiongelmasta, koska se ohittaa asiakasohjelman resolverivalinnan kokonaan.

nslookup intranet.corp.example 10.20.0.53
nslookup intranet
resolvectl status

Ensimmäinen komento kysyy tietyltä palvelimelta täysin kvalifioitua nimeä. Jos se vastaa, resolveri ja reitti sinne ovat kunnossa ja vika on valinnassa tai suffiksissa. Jos aika loppuu, osoite on väärä tai tavoittamaton ja ongelma on reitityksessä, ei DNS:ssä. Toinen komento näyttää, mitä lyhyelle nimelle tapahtuu, ja kolmas tulostaa resolverin kokoonpanon linkeittäin systemd-isännässä.

Varo jokerivastauksia, joita jotkin verkot palauttavat tuntemattomille nimille. Uskottava vastaus ei todista, että tarkoitettu palvelin vastasi, joten vertaa palautettua osoitetta siihen, jota sisäinen palvelu todella käyttää. Jos osoite kuuluu pysäköintisivulle tai välityspalvelimelle, resolveri vastasi mutta vastaus ei ollut koskaan sinun. Tämä ero säästää tunnin tunnelin jäljittämiseltä, joka toimi koko ajan.

Linuxissa VPN-asiakasohjelma, joka kirjoittaa /etc/resolv.conf uudelleen, korvaa paikalliset resolverit kokonaan. vpnc paljastaa DNSUpdate no estääkseen sen, ja systemd-resolved voi ohjata tunnelilinkille vain luetellut toimialueet. Molemmat lähestymistavat pitävät julkiset nimet paikallisella resolverilla ja lähettävät sisäiset nimet toimistoon.

Vuodot ovat sääntö, eivät valintaruutu

Nimien ratkaisu on UDP-vaihto porttiin 53, joten tunneli, joka kuljettaa verkkoliikennettä mutta ei UDP:tä, jättää kyselyn fyysiselle polulle. Todista se kaappaamalla fyysiseltä verkkokortilta, kun julkinen nimi ratkeaa. Kysely, joka näkyy kyseisellä liitännällä luettavassa muodossa, tarkoittaa, ettei tunneli kuljeta sitä.

sudo tcpdump -ni eth0 -c 20 'udp port 53'
resolvectl query example.com

Jos kysely ilmestyy kyseiselle liitännälle luettavassa muodossa, tunneli ei kuljeta sitä. Korjaus on sääntö, joka sallii portin 53 vain VPN:n työntämälle resolverille ja pudottaa muut kohteet, sekä asiakasohjelman kokoonpano, joka ei hiljaa hylkää työnnettyä vaihtoehtoa.

Viimeinen osa on tärkeämpi kuin miltä näyttää. Käynnistä OpenVPN valinnalla route-nopull, niin työnnetty DNS-vaihtoehto katoaa reittien mukana, ellei vetosuodatinta laajenneta pitämään sitä. Ja asiakasohjelma, joka jättää dhcp-option DNS huomiotta, jatkaa sen käyttöä, mitä sillä oli ennen. Jokainen palvelinpuolen muutos vaatii uuden istunnon astuakseen voimaan, koska resolveriluettelo toimitetaan tunnelin noustessa ja vanha istunto näyttää yhä vanhaa tilaa.

Kirjaa, minkä vian todella havaitsit ennen kuin suljet tiketin. Puuttuva sisäinen vastaus ja tunnelista karkaava kysely vaativat eri korjaukset, ja suffiksin muutos, joka korjaa ensimmäisen, voi hiljaa pahentaa toista. Seuraavaksi tiketin ottava luottaa etikettiin, joten tee etiketistä tarkka.