Näin tarkistat DNS-resolverit, joita Mac käyttää VPN:ssä

scutil --dns tulostaa resolverin kokoonpanon, jota macOS todella käyttää, ei sitä yhtä DNS-palvelinta, jonka kirjoitit asetuspaneeliin. Tuloste on pidempi kuin useimmat odottavat, koska järjestelmä pitää erillisiä resolverilohkoja oletuspolulle, rajatuille liitännöille ja toimialuekohtaiselle edelleenlähetykselle. Tulosteen ylimmäinen lohko ei välttämättä ole se, joka vastaa kyselyyn. Jos yksityinen nimi ratkeaa toimistossa ja epäonnistuu heti, kun VPN nousee, epäsuhta on täsmäytyssäännöissä ja reiteissä, ei palvelimen osoitteessa. Lue ensin järjestys ja todista sitten vastaus oikealla haulla.

Lue lohkojen järjestys ennen osoitteita

Jokainen merkintä alkaa resolver #N-merkillä ja luettelee nameserver[0], joskus if_index, rivin flags, reach ja kun lohko ei ole pelkkä oletus, domain ja search domain-luettelon. Resolveri numero 1 ilman toimialuetta on oletus, joka hoitaa julkiset nimet. Kaikki, mikä kantaa lipuissaan Scoped, on sidottu liitäntään, jonka if_index nimeää, ja kaikki Supplemental-merkinnällä varustettu koskee vain sen alla lueteltuja toimialueita.

Valinta on päätteen täsmäytystä. Nimen, kuten intranet.corp.example, kohdalla macOS suosii resolveria, jonka domain-merkintä on pisin täsmäävä pääte, joten lohko, jossa on domain : corp.example, voittaa oletuksen, vaikka se olisi tulosteessa hyvin alhaalla. order ratkaisee tasapelit samanpituisten toimialueiden välillä. Ensikatsaus tarvitsee harvoin enempää: koko tulosteen, kun haluat lukea yhden lohkon alusta loppuun, alkurivit lohkojen järjestyksen oppimiseen ja suodatetun kierroksen, joka tulostaa lohkojen otsikot kenttärivien viereen. Rajatut lohkot näkyvät oman otsikkonsa alla ja luetaan yläpuolisen luettelon jatkona, joten pidä otsikko näkyvissä aina, kun lainaat tulostetta.

scutil --dns
scutil --dns | sed -n '1,45p'
scutil --dns | grep -nE '^resolver #|^DNS configuration'
scutil --dns | grep -nE 'resolver #[0-9]+|if_index|domain|flags|nameserver'

Yhdistä if_index tunneliliitäntään

Indeksistä on hyötyä vain, jos pystyt nimeämään sen takana olevan liitännän. scutil --nwi luettelee verkkotiedot, joita järjestelmä pitää, mukaan lukien ensisijainen liitäntä ja tavoitettavuus, kun taas ifconfig -l antaa nimet, joissa utun0–utun9 ovat tunneliehdokkaat, jotka asiakas yleensä luo. Apple käyttää scutil --dns omana tarkistusesimerkkinään käyttöönotto-oppaassa, ja dokumentoi, miten Network Extension voi ohjata valittuja toimialueita valituille resolvereille, ja juuri tämän mekanismin nuo rajatut lohkot paljastavat.

Kysymyksen ratkaiseva tarkistus on, onko resolveri polulla, jonka tunneli asensi:

scutil --nwi
ifconfig utun4
route -n get 10.20.0.53
netstat -rn | grep -m5 utun

Jos route -n get palauttaa yhdyskäytävän ja liitännän, jotka eivät vastaa resolverimerkintää, osoite voi olla täysin oikea ja silti tavoittamaton. Jaettu tunneli, joka kuljettaa vain yrityksen aliverkot, pudottaa niiden ulkopuolelle suunnatut DNS-palvelinkyselyt, ja vika näkyy aikakatkaisuna, siksi kokoonpanon tuloste näyttää yhä siistiltä.

Kysy järjestelmän resolverilta ja sitten palvelimelta

Kolme työkalua vastaa kolmeen eri kysymykseen, ja niiden sekoittaminen tuottaa suurimman osan tämän alan vääristä johtopäätöksistä. dscacheutil -q host -a name kulkee saman järjestelmäresolverin kautta, jota tavalliset sovellukset käyttävät, joten rajattuja ja täydentäviä lohkoja sovelletaan. dig ilman palvelinargumenttia lukee /etc/resolv.conf-tiedoston, joka ei ole rajatun ratkaisun totuuden lähde macOS:ssä, ja se ohittaa toimialuekohtaiset säännöt kokonaan. dig @address tavoittaa täsmälleen yhden palvelimen eikä kerro valinnasta mitään.

dscacheutil -q host -a name intranet.corp.example
dig intranet.corp.example
dig @10.20.0.53 intranet.corp.example
nslookup intranet.corp.example

Kun ensimmäinen komento vastaa ja toinen palauttaa NXDOMAINin, olet löytänyt etsimäsi jaon eikä mikään ole rikki. Kun ensimmäinen aikakatkaisee samalla kun dig @10.20.0.53 vastaa, resolveri toimii mutta ei ole tavoittamaton tunnelin valitsemalla polulla, joten seuraava askel on route -n get eikä DNS-asetusten muokkaus. Pidä yksityiset nimet poissa kaikesta, mitä liität tikettiin tai jaettuun muistiinpanoon.

Mitä tuloste ei voi näyttää sinulle

Resolveriluettelon yllä tai vieressä istuu useita kerroksia, ja jokainen voi lähettää kyselyn jonnekin, mitä tuloste ei koskaan mainitse. Selain, jossa suojattu DNS on päällä, voi ratkaista oman salatun kanavansa kautta, joten sivu, joka latautuu samalla kun dscacheutil aikakatkaisee, ei ole ristiriita. Tietoturvaohjelmiston asentama DNS-välityspalvelin toimii Network Extension -tarjoajana ja välittää kyselyt itse, ja scutil --dns näyttää, mitä määritettiin, ei ylävirran osoitetta, jota välityspalvelin lopulta käytti. Hakutoimialueet lisäävät kolmannen mutkan: täydentämättömään nimeen lisätään jokainen lueteltu pääte järjestyksessä, joten vastannut lohko voi olla sellainen, jota et koskaan epäillyt.

Vanhentuneet vastaukset on halvin sulkea pois ja useimmin ohitettu:

sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder
scutil --dns | head -20

Jos tuloste muuttuu tyhjennyksen jälkeen, tila oli välimuistissa ja aiempi tuloste kuvasi tunnelia, jota ei enää ollut. Jos se ei muutu, kokoonpano on sellainen kuin se on, ja kysymys siirtyy reitteihin ja sovelluskäytäntöön.

Lyhyt ohje ennen ja jälkeen

Ota lähtötaso vain siellä, missä käytäntö sallii, ja pidä tiedostot poissa mistään synkronoidusta kansiosta. Alla oleva järjestys on se, jonka ajan asiakaskoneilla: ota lähtötaso, yhdistä, ota uudelleen, sitten vertaa ja hae.

scutil --dns > ~/dns-before.txt
# connect the VPN, then:
scutil --dns > ~/dns-after.txt
diff -u ~/dns-before.txt ~/dns-after.txt
dscacheutil -q host -a name intranet.corp.example

Lue ero lohkoittain, älä riveittäin. Uusi rajattu resolveri, joka kantaa tunneliliitännän indeksin ja yksityisen päätteen domain-merkinnän, on odotettu muoto. Uusi oletusresolveri, joka osoittaa julkiseen osoitteeseen, on löydös, joka kannattaa nostaa esiin asiakasprofiilin omistajalle. Toista sitten haku sovelluksessa, joka todella epäonnistui, ei vain kuoressa, ja merkitse liitäntä route -n get-kohdasta tuloksen viereen.

Peruaksesi muutoksen katkaise yhteys ja toista lähtötason otto. Jos rajattu lohko on poissa, asiakas siivosi jälkensä. Jos lohko on yhä listattuna liitäntää vasten, jota ei enää ole, tila on vanhentunut, ja tyhjennys sekä uudelleenyhdistäminen on lempein korjaus ennen kuin kukaan koskee profiiliin.

Neljä tarkistusta tässä järjestyksessä: täsmääkö jokin resolverilohko nimen pisimpään päätteeseen, onko lohko sidottu liitäntään, jonka tunneli asensi, käyttääkö reitti sen nimipalvelimelle tunnelia, ja palauttaako vastauksen järjestelmän resolveri eikä dig. Ensimmäinen epäonnistuva tarkistus kertoo, muutatko DNS-käytäntöä, tunnelin reittejä vai sovellusta. Jos kaikki neljä menevät läpi ja nimi epäonnistuu yhä, ongelma on DNS:n yläpuolella, ja seuraava tarkistettava on kaikki, mikä vastaa sen edessä porttiin 53.