Sekite DNS užklausą žingsnis po žingsnio, kad rastumėte tikrąjį šaltinį
Primesta resolverio adresas nenulemia, kokį šaltinį mato resolveris. Sekite klientą, peradresuotoją ir priimantį serverį, tada užrašykite kelią.
Davus klientui resolverio adresą, nustatoma, kur siunčiamos užklausos, o ne kokį šaltinį matys resolveris. Maršrutizavimas, persiuntimas ir vertimas kiekvienas gauna savo eilę tarp dviejų galų. Šaltinio klausimų vadovas seka užklausą žingsnis po žingsnio ir užrašo, ką kiekvienas stebėtojas iš tikrųjų matė. Tvarka svarbi, nes teiginys, pasakytas prieš stebėjimą, tėra spėjimas geresniu formatu.
Užrašykite išdėstymą prieš rinkdami įrodymus
Keturi taškai gali ką nors pasakyti apie DNS šaltinį, ir ne visi sako tą patį. Kliento branduolys žino, kokį šaltinį naudotų, peradresuotojas žino, ką nusiuntė aukštyn, verčiantis įrenginys žino, ką perrašė, o priimantis resolveris žino, kas atėjo. Užrašykite, kuriuos iš jų iš tikrųjų galite pasiekti, prieš ką nors rinkdami.
| Observation point | What it can prove | What it cannot prove | How to read it |
|---|---|---|---|
| client kernel | which source address it would use for that resolver | anything a device in between rewrote | ip route get against the resolver address |
| forwarder | that it sent an upstream query, and from which source | what the client originally asked for | its own log and its cache state |
| translating device | that a source was rewritten, and to what | whether the query was legitimate | NAT policy and its counters |
| receiving resolver | the address that actually arrived | which client behind that address asked | a scoped capture on port 53 |
Užrašykite ir savo lūkestį, įskaitant resolverį, kuris, jūsų manymu, naudojamas. Padalytas maršrutas gali nusiųsti užklausą visai kitur, o podėlis gali atsakyti be jokio aukštyn vykstančio pasikeitimo, todėl tik atmintyje laikoma prielaida neišgyvens pirmos staigmenos. Laikykite deklaruotą projektą ir stebėtą kelią atskiruose tos pačios pastabos stulpeliuose; kai šie du nesutampa, radote klausimą, kurį verta persekioti.
Patikrinkite, kuris procesas užklausą iš tikrųjų nusiuntė
Pradėkite nuo kliento: užrašykite resolverio adresą, užklausos vardą ir laiką, tada patvirtinkite, kuris procesas ją nusiuntė. Pirmoji eilutė žemiau įvardija procesą, laikantį UDP lizdą, ir tai yra patikra, kurią žada ši antraštė. Jei tas procesas yra naršyklės pagalbininkas arba konteinerio vykdymo aplinka, o ne sistemos resolveris, likusi pėdsako dalis aprašo kelią, kurio niekas neprašė.
ss -tunp 'dport = :53'
dig @10.20.30.53 host.corp.example +noall +answer
ip route get 10.20.30.53Hoste su keliais sąsajomis pirmiausia išsiaiškinkite, kokį šaltinio adresą branduolys pasirenka tam tikslui, prieš žiūrėdami kur nors kitur. Tai paskutinis taškas, kai kelias visiškai jūsų kontrolėje, ir tai reikšmė, kurią palyginsite su tuo, ką praneša resolveris. Neatitikimas yra signalas, kad kažkas tarp jų perrašė paketą arba buvo nusiųstos dvi skirtingos užklausos.
Laikykite testinius vardus vidinius, nes vidinis vardas, nusiųstas viešajam resolveriui, nieko neįrodo apie vidinį kelią ir paskelbia vardą, kurio jums nereikėjo skelbti. Naršyklė su įjungtu saugiu DNS tame lizdų sąraše visai nepasirodys, ir tos nebuvimas pats yra atsakymas.
Peradresuotojas atlieka antrą, atskirą užklausą
Peradresuotojas vieną mainus paverčia dviem. Užklausa iš apačios ateina, o tada peradresuotojas siunčia savo užklausą aukštyn iš jo pasirinkto adreso. Jo konfigūracija, o ne klientas, nulemia, ką mato viršutinis resolveris.
dnsmasq vadovas vertas skaityti būtent todėl: jame aprašoma, kaip peradresuotojas parenka viršutinius serverius ir susieja savo klausymosi pusę, ir niekas tame išdėstyme neneša kliento šaltinio aukštyn. Todėl resolverio žurnalas, rodantis tinklų sietuvos adresą, yra normalus, o ne gedimo įrodymas. Nebuvimą taip pat lengva perskaityti neteisingai, nes podėlio pataikymas nesukuria jokios užklausos aukštyn ir atrodo lygiai taip pat kaip užklausa, kuri niekada neatėjo. Perskaitykite peradresuotojo konfigūraciją ir jo podėlio būseną prieš darydami bet kurią iš dviejų išvadų. Du klausimai, dvi vietos, kur žiūrėti.
Perskaitykite šaltinį priimančiame resolveryje
Vienintelis stebėjimas, kuris tai išsprendžia, atliekamas serverio pusėje. Viskas, kas išvedama iš kliento sąsajų sąrašo, lieka hipoteze, kol resolveris nepraneš, kas iš tikrųjų atėjo.
tcpdump -ni any port 53 and host 10.20.30.53Fiksuokite resolverio hoste, laikykite fiksavimą trumpą ir apribotą, ir saugokite jį ten, kur leidžia politika. Jei stebimas šaltinis yra išverstas adresas, kitas klausimas – kuris įrenginys atliko vertimą ir ar jo politika yra numatytoji. Fiksavimas atsako, kas atėjo; jis nepaaiškina, kodėl politika tai leido. Įvardykite stebėtoją ir žingsnį pastaboje, nes privatumo teiginys apie tinklų sietuvą yra teiginys apie tą žingsnį, o ne apie visą kelią.
Užrašykite radinį kaip kelią, o ne kaip adresą
Užrašykite klientą, resolverį, bet kurį peradresuotoją, stebėtą šaltinį kiekviename žingsnyje ir politiką, kuri jį valdo. Toks įrašas atsako į daugumą būsimų klausimų be naujo fiksavimo. Nupieškite jį kaip grandinę, nes adresų sąrašas slepia, kuris žingsnis davė kurią.
Prikabinkite prie brėžinio datą, kliento versiją ir konfigūracijos reviziją, kad vėlesnis skaitytojas galėtų pasakyti, ar ji dar galioja. Atskirkite transporto šaltinį nuo visko kito, ką apdoroja paslauga, nes tinklų sietuvos adreso matymas nieko nesako apie tai, kas dar saugoma. Resolverio vieta taip pat nieko nesako apie tai, kuris klientas klausė. Būtent šių teiginių atskyrimas daro išvadą apginamą peržiūroje.