Hvorfor DNS-svaret mislykkes på en tilstandsløs VPN-kantbrannmur

Tunnelen er oppe, klientene når VPN-verten, og verten får ikke slått opp noe. Dens egne utgående spørringer forlater grensesnittet rent, så feilen ligger på veien tilbake: ved en kant lenger oppe som filtrerer innkommende trafikk uten å huske hva verten nettopp sendte. Å tillate tunnelporten beskriver slett ikke den utvekslingen. Svaret på en DNS-spørring er en egen strøm, og hvis kanten er tilstandsløs, har ingenting gitt den tillatelse til å komme tilbake.

De to utvekslingene er ikke den samme utvekslingen

Skriv ned tuppelene, og feilen blir åpenbar. Forespørselens målport blir svarets kildeport, som er det motsatte av hva folk flest ser for seg når de legger til en innkommende regel for 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 innkommende regel som krever målport 53 beskriver trafikk adressert til en DNS-lytter som kjører på verten, og det er en helt annen tjeneste. Disse adressene er dokumentasjonseksempler, og kildeporten velges av klienten for hver spørring, så det er ikke en verdi du kan kopiere inn i en regel og forvente at den fortsetter å virke.

Tilstandsløs kant kontra tilstandsbasert vertsbrannmur

Et tilstandsløst kantfilter vurderer hver innkommende pakke mot regellisten sin uten noen tilknytningstabell bak seg. En utgående spørring som kom seg ut, skaper ingen tillatelse for sitt innkommende svar, fordi enheten ikke har noen registrering av at en spørring noen gang fant sted. En tilstandsbasert vertsbrannmur er det motsatte: dens tilkoblingssporing gjenkjenner returtrafikken til en tillatt utveksling og slipper den gjennom uten en regel for svaret. Begge grensene finnes i en typisk bane, og begge må tillate den tiltenkte pakken.

Sammenligningen betyr noe fordi de to enhetene feiler ulikt. En tilstandsbasert brannmur som avviser svaret, logger et dropp; en tilstandsløs kant avviser det stille, og derfor går verten rett og slett i tidsavbrudd.

Bygg tillatelsen rundt protokollen, ikke et portnummer

Begrens regelen til de faktiske adressene til resolveryteren, målverten og mottaksport-policyen som produktet støtter. Husk også TCP-veien til DNS, fordi et stort svar eller en tilbakefall ved trunkering flytter utvekslingen til TCP, og en regel bare for UDP dekker den ikke. Hvis kanten støtter tilstandsbasert inspeksjon for en definert strøm, foretrekk det fremfor en håndskrevet svarregel, fordi den tilstandsbaserte veien følger portene klienten velger automatisk.

Bekreft deretter hvilket produkt i banen som faktisk filtrerer trafikken. Et dokumentert IPv4-kantområde etablerer ikke en IPv6-policy, og leverandørintern trafikk går kanskje aldri gjennom det samme filteret.

Hvorfor det ikke er en løsning å tillate enhver kildeport 53

En regel som godtar alt som hevder å ha kildeport 53, er en regel som godtar det en avsender skriver i et headerfelt. Portnummeret autentiserer ikke avsenderen og beviser ikke at nyttelasten er et gyldig svar, så regelen øker vertens eksponering uten å gjøre oppslaget mer pålitelig. Behold kildebegrensninger og behold klientens egne svarkontroller, inkludert randomisering av kildeport, i stedet for å slå dem av for å forenkle en tilgangsliste.

Hvis resolveryteren er en tjeneste du kontrollerer, er det nok å begrense til adressene dens. Hvis den er en offentlig resolveryter, begrens til adressene du har godkjent, og noter dem i kommentaren til regelen.

Verifiser ved riktig grense, i riktig retning

Ta opp på verten og ved kanten for den samme spørringen, og sammenlign tuppelene i stedet for pakketellingene. En spørring som er synlig på begge sider uten et svar synlig på vertssiden, peker på det innkommende filteret; en spørring som bare er synlig på vertssiden, peker på ruting eller resolveryteren selv. Gjenta med en TCP-spørring hvis du bare har tillatelse for UDP, fordi det er hullet den første testen ikke kan se.

Å rette dette fullfører en DNS-utveksling som verten virkelig trenger. Det gjør ikke verten til en offentlig resolveryter, tillater ikke videresendte VPN-strømmer og beviser ikke at DNS var årsaken til et eller annet urelatert tunnelproblem.