Salli DNS vain oman VPN-resolverisi kautta: vaiheittainen läpikäynti

Seuraa yhtä nimikyselyä siitä hetkestä, kun kirjoitat sen. Selain kysyy käyttöjärjestelmältä, käyttöjärjestelmä kysyy resolverilta, jonka sen käytäntö valitsee, ja kysely poistuu laitteesta jonkin rajapinnan kautta jollakin kuljetuksella. VPN-suunnitelmasi sanoo, että vastauksen pitäisi tulla tietystä resolverista tiettyä polkua pitkin. Näiden kahden väitteen välinen ero on se, mitä määrität ja sitten valvot.

Vaihe 1: nimeä resolver ja polku

Kirjoita kolme asiaa muistiin ennen kuin kosket palomuuriin: resolverin osoite, odottamasi protokolla ja portti sekä rajapinta, jota pitkin kyselyn pitää lähteä. Ilman tätä luetteloa sääntö on arvaus liikenteestä eikä päätöksen täytäntöönpanoa. VPN voi kuljettaa sovellusten dataa samalla kun DNS noudattaa erillistä järjestelyä, eikä se sinänsä ole virhe. Se on sitä, mitä tapahtuu, kun kukaan ei ole kertonut asiakkaalle muuta.

Polun nimeäminen selvästi on ero suunnitelman ja sattuman välillä. Se antaa sinulle myös jotain testattavaa myöhemmin, koska jokaista havaintoa voi verrata kirjalliseen odotukseen. Pidä luettelo muutostiketissä, älä jonkun päässä.

Vaihe 2: aseta käytäntö sinne, missä se todella asuu

Resolverin valinta kuuluu asiakkaalle: käyttöjärjestelmän verkkoasetukset, VPN-asiakkaan omat asetukset tai hallittu selainkäytäntö. Aseta se ensin sinne, alustan tukemalla mekanismilla, koska palomuuri ei voi pakottaa asiakasta valitsemaan resolveria, josta se ei ole koskaan kuullut. Jaetun tunnelin asiakkaassa sano selvästi, mitkä verkkotunnukset menevät sisäiselle resolverille. Hallitussa laivueessa selainkäytäntö on usein ainoa vipu DoH:lle, koska selain voi valita oman salatun resolverinsa järjestelmäasetuksesta riippumatta.

Ohita tämä ja mene suoraan palomuurille, niin saat säännön, joka sallii oikean resolverin, sekä asiakkaan, joka ei koskaan käytä sitä. Sääntö näyttää oikealta ja resolverin lokit pysyvät tyhjinä, mikä on hämmentävä pari vianetsinnässä. Määritä ensin valinta ja valvo se sitten.

Vaihe 3: valvo polkua kapeasti

Lisää nyt verkkolupa sallitulle polulle: resolverin osoite, protokolla ja portti sekä rajapinta, jonka kautta sen pitää lähteä. Pidä sääntö rajattuna tuohon resolveriin sen sijaan, että sallit kaiken lähtevän DNS:n. Kolme alla olevaa polkua ovat niitä, joita nykyaikainen asiakas voi käyttää, ja vain ensimmäisen kattaa portin 53 sääntö.

DoH:n ja DoT:n estäminen on laillista; sen olettaminen, että portin 53 sääntö on jo estänyt ne, ei ole. DoH:ta käyttävä selain ratkaisee nimiä polkua pitkin, jota sääntösi ei koskaan kuvannut, ja oman resolverinsa mukanaan tuova sovellus tekee samoin. Kirjoita ylös jokainen polku, jonka aiot sallia, ja jokainen, jonka aiot hylätä. Sääntö, joka ei nimeä polkua, ei ole päättänyt siitä.

Vaihe 4: seuraa yksityisiä ja julkisia nimiä

Jaettu DNS lähettää tarkoituksella vain yksityiset nimiavaruudet sisäiselle resolverille, kun taas julkiset nimet menevät muualle, joten useampi kuin yksi resolver suunnitelmassa ei ole vuoto. Vuoto on kysely, jonka olisi pitänyt mennä resolverillesi ja joka saapuu muualle, tai saavuttamaton aiottu polku, joka saa asiakkaan putoamaan takaisin hiljaa. Ne kaksi tapausta ovat se, mitä etsiä. Seuraa sisäistä ja julkista nimeä aiotun käytännön alla ja merkitse, mikä resolver vastasi kumpaankin.

Testisivusto, joka raportoi resolverisi, on vihje, ei todiste, koska se näkee vain ne kyselyt, jotka pääsivät perille. Sieppaa kysely asiakkaan puolella, kun sinun on tiedettävä, minkä polun se todella valitsi, ja vertaa molempia havaintoja. Kun ne ovat eri mieltä, olet löytänyt takaisinputoamisen, jota kukaan ei dokumentoinut.

Jos resolverin osoite on oikea mutta saavuttamaton, ongelma on reitityksessä tai suodatuksessa, ei käytännössä. Jäljitä kysely tuohon osoitteeseen ja varmista, että vastaus palaa odotetulta rajapinnalta, ennen kuin muutat mitään resolverin asetusta.

Vaihe 5: pidä paluupolku auki

Ennen kuin kiristät yhdyskäytävän DNS-pääsyä, varmista palautusmenetelmä, joka ei riipu nimien ratkaisemisesta. Rikkinäinen resolver vaikeuttaa kaikkien korjaustyökalujen saavuttamista, myös niiden, joilla peruisit muutoksen. Pidä paikallinen konsoli tai kaistan ulkopuolinen polku auki, kunnes uusi käytäntö on todistettu. Poista se vasta, kun käytäntö on kestänyt uudelleenyhdistämisen.

Tarkastele tehokas tila uudelleen uudelleenyhdistämisen tai selainkäytännön päivityksen jälkeen, koska molemmat voivat vaihtaa resolverin muuttamatta sääntöäsi. Vaatimus on tunnettu vastaanottaja ja suojattu polku kyselyille, ei yhdessä kuvakaappauksessa rauhoittava resolverin tarra. RFC 8484 DNS over HTTPS -spesifikaatio on viite salatulle polulle, jota porttisääntösi ei näe.