Varför DNS-svaret misslyckas vid en tillståndslös VPN-kantbrandvägg

Tunneln är uppe, klienterna når VPN-värden, och värden kan inte lösa något. Dess egna utgående frågor lämnar gränssnittet rent, så felet ligger på vägen tillbaka: vid en kant längre upp som filtrerar inkommande trafik utan att minnas vad värden just skickade. Att tillåta tunnelporten beskriver inte alls det utbytet. Svaret på en DNS-fråga är ett eget flöde, och om kanten är tillståndslös har ingenting gett det tillstånd att komma tillbaka.

De två utbytena är inte samma utbyte

Skriv ned tuplarna och felet blir uppenbart. Förfrågans målport blir svarets källport, vilket är motsatsen till vad de flesta föreställer sig när de lägger till en inkommande regel för port 53:

query:  203.0.113.10:53018 -> 198.51.100.53:53
reply:  198.51.100.53:53 -> 203.0.113.10:53018

En inkommande regel som kräver målport 53 beskriver trafik adresserad till en DNS-lyssnare som körs på värden, och det är en helt annan tjänst. De adresserna är dokumentationsexempel, och källporten väljs av klienten för varje fråga, så det är inte ett värde du kan kopiera in i en regel och förvänta dig att det fortsätter att fungera.

Tillståndslös kant kontra tillståndsbaserad värdbrandvägg

Ett tillståndslöst kantfilter utvärderar varje inkommande paket mot sin regellista utan någon anslutningstabell bakom sig. En utgående fråga som kom ut skapar inget tillstånd för sitt inkommande svar, eftersom enheten inte har någon registrering av att en fråga någonsin ägde rum. En tillståndsbaserad värdbrandvägg är det motsatta: dess anslutningsspårning känner igen returtrafiken från ett tillåtet utbyte och släpper igenom den utan en regel för svaret. Båda gränserna finns i en typisk väg, och båda måste tillåta det avsedda paketet.

Jämförelsen spelar roll eftersom de två enheterna misslyckas olika. En tillståndsbaserad brandvägg som nekar svaret loggar ett drop; en tillståndslös kant nekar det tyst, vilket är därför värden helt enkelt får timeout.

Bygg tillståndet kring protokollet, inte ett portnummer

Begränsa regeln till den faktiska resolverns adresser, målvärden och den mottagningsportpolicy som produkten stöder. Tänk också på DNS TCP-väg, eftersom ett stort svar eller ett fall tillbaka vid trunkering flyttar utbytet till TCP och en regel bara för UDP täcker det inte. Om kanten stöder tillståndsbaserad inspektion för ett definierat flöde, föredra det framför en handskriven svarsregel, eftersom den tillståndsbaserade vägen automatiskt följer de portar klienten väljer.

Bekräfta sedan vilken produkt i vägen som faktiskt filtrerar trafiken. Ett dokumenterat IPv4-kantområde etablerar ingen IPv6-policy, och leverantörsintern trafik passerar kanske aldrig samma filter.

Varför det inte är en lösning att tillåta vilken källport 53 som helst

En regel som accepterar allt som påstår sig ha källport 53 är en regel som accepterar vad en avsändare skriver i ett rubrikfält. Portnumret autentiserar inte avsändaren och bevisar inte att nyttolasten är ett giltigt svar, så regeln ökar värdens exponering utan att göra uppslagningen mer tillförlitlig. Behåll källbegränsningar och behåll klientens egna svarskontroller, inklusive slumptal för källporten, i stället för att stänga av dem för att förenkla en åtkomstlista.

Om resolvern är en tjänst du kontrollerar räcker det att begränsa till dess adresser. Om den är en offentlig resolver, begränsa till de adresser du har godkänt och anteckna dem i regelns kommentar.

Verifiera vid rätt gräns, i rätt riktning

Fånga på värden och vid kanten för samma fråga, och jämför tuplarna i stället för paketräkningarna. En fråga som syns på båda sidor utan ett svar som syns på värdsidan pekar på det inkommande filtret; en fråga som bara syns på värdsidan pekar på routning eller resolvern själv. Upprepa med en TCP-fråga om du bara har tillstånd för UDP, eftersom det är hålet som det första testet inte kan se.

Att åtgärda detta slutför ett DNS-utbyte som värden verkligen behöver. Det gör inte värden till en offentlig resolver, tillåter inte vidarebefordrade VPN-flöden och bevisar inte att DNS var orsaken till något orelaterat tunnelproblem.