Split-DNS-kaappaus: kerro, missä kukin havainto tehtiin

Kaksi ihmistä selvittää samaa Split-DNS-ongelmaa ja saa eri resolver-osoitteet. Toinen käytti hakutyökalua, toinen kaappasi paketteja sovittimella ja kolmas luki asiakkaan omat diagnostiikat. Kukaan heistä ei valehtele, eikä kukaan kuvaa samaa vaihetta. Havaintopisteen nimeäminen muuttaa ristiriidan kartaksi.

Yksi haku, useita havaintopisteitä

Yhdelle sisäiselle nimelle on ainakin viisi paikkaa katsoa: sovellus ja sen kutsuma resolver-API, asiakkaalla voimassa oleva verkkotunnuskäytäntö, kaappaus sovittimella tai suodattimella, valvottu yhdyskäytäväraja ja resolver, joka todella vastaanottaa kyselyn.

Kukin vastaa eri kysymykseen, eikä mikään yksin todista, minne kysely meni.

Sovittimella tehty kaappaus näyttää paketit, ei aikomusta. Se ei kerro, minkä resolverin asiakas valitsi, ja tyhjä kaappaus voi tarkoittaa välimuistiin tallennettua vastausta tai toista resolver-APIa pudotetun paketin sijaan. Käsittele jokaista havaintoa todisteena yhdestä vaiheesta. Kokoa sitten vaiheet poluksi.

Asiakkaan suodatin on sovelluksen ja johdon välissä

Split-DNS:ää käyttävä VPN-asiakas soveltaa verkkotunnusten täsmäytystä ennen kuin paketti lähtee koneesta. Tunneloidun suffiksin nimet menevät sisäiselle resolverille; kaikki muu menee paikalliselle. Suodatin on käytäntö, ja käytäntö voi vaihdella alustan ja asiakasversion mukaan.

Ciscon Secure Clientin Split-DNS-ohje kattaa verkkotunnusten täsmäytyksen ja Windows-suodattimen, ja se erottaa sen, mitä sovellus näkee käyttäessään natiivia resolver-APIa, siitä, mitä nslookupin kaltainen työkalu näkee. Juuri ne erot ovat pointti.

Aloita voimassa olevasta profiilista ja yhdestä tavallisesta sovellushakukyselystä. Jokainen testi, joka nimeää tietyn palvelimen, on tarkoituksellinen kiertotie; selitä se asiakkaan omalla diagnostiikalla, äläkä anna siitä hyväksymiskriteeriä.

nslookup kulkee eri polkua kuin sovellus

nslookup rakentaa oman DNS-kyselynsä ja voi ohittaa käyttöjärjestelmän resolver-käytännön. Se tekee siitä hyödyllisen työkalun tietyn kysymyksen esittämiseen tietylle palvelimelle ja harhaanjohtavan työkalun testaamaan, mitä sovellus kokee.

Windowsissa nimien ratkaisun käytäntötaulukko päättää, mikä suffiksi käyttää mitä palvelinta. Sen lukeminen näyttää käytännön, jota sovellus seuraa, ja se on usein puuttuva palanen.

Lue käytäntö ja esitä sitten sama kysymys tavallisen resolverin kautta:

Get-DnsClientNrptPolicy
Resolve-DnsName intranet.hq.example

Salatut resolverit piilottavat kyselyn, eivät yhteyttä

Selain, jolla on oma DNS-over-HTTPS-resolveri, on täysin toinen tapaus. Kysely lähtee TLS:n sisällä, joten pakettikaappaus näyttää yhteyden resolver-osoitteeseen mutta ei kysyttyä nimeä.

Selvitä ensin selaimen hallittu käytäntö ja vertaa sitä sitten käyttöjärjestelmän hakuun. Selain, jolla on lupa valita oma resolverinsa, ei ehkä näe Split-DNS-käytäntöä lainkaan.

Sama varovaisuus koskee mitä tahansa asiakasta, joka toimittaa oman resolverinsa. Kaappaus, joka tunnistaa etäyhteyden, ei ole todiste kyselyn nimestä. Jos tarvitset nimen, ota se resolverin omista lokeista tai sovelluksen diagnostiikasta sovellettavien tietosuojasääntöjen mukaisesti.

Vertaa merkittyyn testiin

Valitse testausta varten hyväksytty sisäinen nimi sekä julkinen nimi, jolla ei ole arkaluontoista merkitystä. Kirjaa kullekin aika, tietuetyyppi, vastaus ja odotettu käytäntö.

Missä se on sallittua, vertaa resolverin vastaanottoa yhteen kapeaan asiakkaan tai yhdyskäytävän havaintoon:

nslookup intranet.hq.example 10.55.0.53
Get-DnsClientNrptPolicy | Format-List

Älä koskaan lähetä yksityisiä nimiä asiaankuulumattomille julkisille resolvereille vain vertailun luomiseksi, ja punakoi kaikki jakamasi. Erottele lopuksi oikea DNS-vastaus sitä seuraavasta palveluyhteydestä: ratkaistu yksityinen osoite tarvitsee edelleen reitin ja sovelluksen valtuutuksen.