Tillåt DNS bara via din egen VPN-resolver: en genomgång steg för steg

Följ ett enda namnsök från det ögonblick du skriver det. Webbläsaren frågar operativsystemet, operativsystemet frågar den resolver som dess policy väljer, och frågan lämnar enheten via något gränssnitt med någon transport. Din VPN-design säger att svaret ska komma från en viss resolver via en viss väg. Glappet mellan de två påståendena är det du konfigurerar och sedan verkställer.

Steg 1: namnge resolvern och vägen

Skriv ned tre saker innan du rör en brandvägg: resolverns adress, protokollet och porten du förväntar dig, och gränssnittet som frågan ska gå ut genom. Utan listan är en regel en gissning om trafik och inte verkställande av ett beslut. Ett VPN kan bära applikationsdata medan DNS följer ett separat upplägg, och det är inte ett fel i sig. Det är vad som händer när ingen har sagt något annat till klienten.

Att namnge vägen uttryckligen är skillnaden mellan en design och en olycka. Det ger dig också något att testa senare, eftersom varje observation kan jämföras med en skriftlig förväntan. Förvara listan i ändringsärendet och inte i någons huvud.

Steg 2: sätt policyn där den faktiskt bor

Valet av resolver tillhör klienten: operativsystemets nätverkskonfiguration, VPN-klientens egna inställningar eller en hanterad webbläsarpolicy. Sätt den där först, med den mekanism plattformen stöder, eftersom en brandvägg inte kan tvinga en klient att välja en resolver som den aldrig har hört talas om. På en klient med delad tunnel ska du uttryckligen säga vilka domäner som går till den interna resolvern. I en hanterad flotta är webbläsarpolicyn ofta den enda hävstången för DoH, eftersom webbläsaren kan välja sin egen krypterade resolver oberoende av systeminställningen.

Hoppa över detta och gå direkt till brandväggen, och du får en regel som tillåter rätt resolver plus en klient som aldrig använder den. Regeln ser korrekt ut och resolverloggarna förblir tomma, ett förvirrande par att felsöka. Konfigurera först valet och verkställ det sedan.

Steg 3: verkställ vägen snävt

Lägg nu till nätverkstillståndet för den tillåtna vägen: resolverns adress, protokollet och porten, och gränssnittet den ska gå ut genom. Håll regeln begränsad till den resolvern i stället för att tillåta all utgående DNS. De tre vägarna nedan är de en modern klient kan ta, och bara den första täcks av en regel för port 53.

Att blockera DoH och DoT är legitimt; att anta att en regel för port 53 redan har blockerat dem är det inte. En webbläsare med DoH löser namn via en väg som din regel aldrig har beskrivit, och en applikation som tar med sin egen resolver gör detsamma. Skriv ned varje väg du tänker tillåta och varje väg du tänker avvisa. En regel som inte namnger en väg har inte beslutat något om den.

Steg 4: följ privata och offentliga namn

Delad DNS skickar medvetet bara privata namnrymder till en intern resolver medan offentliga namn går någon annanstans, så mer än en resolver i designen är ingen läcka. Läckan är en fråga som borde ha gått till din resolver och dyker upp någon annanstans, eller en oåtkomlig avsedd väg som får klienten att falla tillbaka tyst. Det är dessa två fall du ska leta efter. Följ ett internt och ett offentligt namn under den avsedda policyn och notera vilken resolver som svarade på varje.

En testsajt som rapporterar din resolver är en antydan, inte ett bevis, eftersom den bara ser de frågor som nådde fram till den. Fånga frågan på klientsidan när du behöver veta vilken väg den faktiskt tog, och jämför sedan de två observationerna. När de inte stämmer har du hittat ett återfall som ingen har dokumenterat.

Om resolveradressen är rätt men oåtkomlig ligger problemet i routing eller filtrering och inte i policyn. Spåra frågan till den adressen och bekräfta att svaret kommer tillbaka på det förväntade gränssnittet innan du ändrar någon resolverinställning.

Steg 5: behåll en väg tillbaka

Innan du stramar åt DNS-åtkomsten på gatewayen ska du bekräfta en återställningsmetod som inte är beroende av namnsökning. En trasig resolver gör varje reparationsverktyg svårare att nå, även dem du skulle använda för att rulla tillbaka ändringen. Håll en lokal konsol eller en väg utanför bandet öppen tills den nya policyn är bevisad. Ta bort den först när policyn har överlevt en återanslutning.

Efter en återanslutning eller en uppdatering av webbläsarpolicyn ska du inspektera det effektiva tillståndet igen, eftersom båda kan ändra resolvern utan att ändra din regel. Kravet är en känd mottagare och en skyddad väg för frågorna, inte en lugnande resolveretikett på en enda skärmbild. RFC 8484-specifikationen för DNS over HTTPS är referensen för den krypterade väg som din portregel inte ser.