Hvorfor DNS-svaret fejler ved en stateless VPN-edgefirewall

Tunnelen er oppe, klienterne kan nå VPN-værten, og værten kan ikke slå noget op. Dets egne udgående forespørgsler forlader grænsefladen rent, så fejlen ligger på vejen tilbage: ved en edge længere oppe, som filtrerer indgående trafik uden nogen erindring om, hvad værten netop har sendt. At tillade tunnelporten beskriver slet ikke den udveksling. Svaret på en DNS-forespørgsel er en separat strøm, og hvis edgen er stateless, har intet givet den tilladelse til at vende tilbage.

De to udvekslinger er ikke den samme udveksling

Skriv tuplerne ned, og fejlen bliver indlysende. Forespørgslens destinationsport bliver svarets kildeport, hvilket er det modsatte af, hvad de fleste forestiller sig, når de tilføjer en indgående 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 indgående regel, der kræver destinationsport 53, beskriver trafik rettet mod en DNS-lytter på værten, hvilket er en helt anden tjeneste. De adresser er dokumentationseksempler, og kildeporten vælges af klienten for hver forespørgsel, så det er ikke en værdi, du kan kopiere ind i en regel og forvente bliver ved med at virke.

Stateless edge kontra stateful vært-firewall

Et stateless edge-filter vurderer hver indgående pakke mod sin regelliste uden nogen forbindelsestabel bag sig. En udgående forespørgsel, der er kommet af sted, skaber ingen tilladelse til sit indgående svar, fordi enheden ikke har nogen registrering af, at der nogensinde har været en forespørgsel. En stateful vært-firewall er det modsatte: dens forbindelsessporing genkender returtrafikken fra en tilladt udveksling og lader den passere uden en regel for svaret. Begge grænser findes på en typisk vej, og begge skal tillade den tilsigtede pakke.

Sammenligningen betyder noget, fordi de to enheder fejler forskelligt. En stateful firewall, der afviser svaret, logger et drop; en stateless edge afviser det lydløst, og derfor løber værten simpelthen ud i tid.

Byg tilladelsen omkring protokollen, ikke et portnummer

Begræns reglen til de faktiske resolveradresser, destinationsværten og den modtagelsesportpolitik, produktet understøtter. Husk også DNS' TCP-vej, fordi et stort svar eller et fald tilbage ved trunkering flytter udvekslingen til TCP, og en regel kun for UDP dækker den ikke. Hvis edgen understøtter stateful inspektion for en defineret strøm, foretræk det frem for en håndskrevet svarregel, fordi den stateful vej automatisk følger de porte, klienten vælger.

Bekræft derefter, hvilket produkt på vejen der faktisk filtrerer trafikken. Et dokumenteret IPv4-edgeområde fastlægger ikke en IPv6-politik, og udbyderintern trafik passerer måske aldrig det samme filter.

Hvorfor tilladelse af enhver kildeport 53 ikke er en løsning

En regel, der accepterer alt, hvad der påstår at have kildeport 53, er en regel, der accepterer, hvad en afsender skriver i et headerfelt. Portnummeret autentificerer ikke afsenderen og beviser ikke, at nyttelasten er et gyldigt svar, så reglen øger værtens eksponering uden at gøre opslaget mere pålideligt. Behold kildebegrænsninger, og behold klientens egne svarchecks, herunder randomisering af kildeport, i stedet for at slå dem fra for at forenkle en adgangsliste.

Hvis resolveren er en tjeneste, du kontrollerer, er det nok at begrænse til dens adresser. Hvis den er en offentlig resolver, så begræns til de adresser, du har godkendt, og noter dem i reglens kommentar.

Verificér ved den rigtige grænse, i den rigtige retning

Optag på værten og ved edgen for den samme forespørgsel, og sammenlign tuplerne i stedet for pakketællingerne. En forespørgsel, der er synlig på begge sider uden et svar synligt på værtssiden, peger på det indgående filter; en forespørgsel, der kun er synlig på værtssiden, peger på routing eller selve resolveren. Gentag med en TCP-forespørgsel, hvis du kun har tilladelse til UDP, fordi det er hullet, som den første test ikke kan se.

At rette dette færdiggør en DNS-udveksling, som værten virkelig har brug for. Det gør ikke værten til en offentlig resolver, tillader ikke videresendte VPN-strømme og beviser ikke, at DNS var årsagen til et eller andet urelateret tunnelproblem.