Kvifor DNS-svaret mislukkast på ein tilstandslaus VPN-kantbrannmur

Tunnelen er oppe, klientane når VPN-verten, og verten får ikkje slått opp noko. Dei eigne utgåande spurnadene forlèt grensesnittet reint, så feilen ligg på vegen tilbake: ved ein kant lenger oppe som filtrerer innkomande trafikk utan å hugse kva verten nettopp sende. Å tillate tunnelporten skildrar slett ikkje den utvekslinga. Svaret på ein DNS-spurnad er ein eigen straum, og om kanten er tilstandslaus, har ingenting gjeve han løyve til å kome tilbake.

Dei to utvekslingane er ikkje den same utvekslinga

Skriv ned tuppela, og feilen blir openberr. Målporten til førespurnaden blir kjeldeporten til svaret, som er det motsette av det folk flest ser føre seg når dei legg til ein innkomande 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

Ein innkomande regel som krev målport 53 skildrar trafikk adressert til ein DNS-lyttar som køyrer på verten, og det er ei heilt anna teneste. Desse adressene er dokumentasjonseksempel, og kjeldeporten blir vald av klienten for kvar spurnad, så det er ikkje ein verdi du kan kopiere inn i ein regel og vente at han held fram med å verke.

Tilstandslaus kant kontra tilstandsbasert vertsbrannmur

Eit tilstandslaus kantfilter vurderer kvar innkomande pakke mot regellista si utan noka tilknytingstabell bak seg. Ein utgåande spurnad som kom seg ut, skapar ikkje noko løyve for det innkomande svaret sitt, fordi eininga ikkje har noka registrering av at ein spurnad nokon gong fann stad. Ein tilstandsbasert vertsbrannmur er det motsette: tilknytingssporinga hans kjenner att returtrafikken til ei tillaten utveksling og slepp han gjennom utan ein regel for svaret. Båe grensene finst i ein typisk bane, og båe må tillate den tiltenkte pakken.

Samanlikninga betyr noko fordi dei to einingane mislukkast ulikt. Ein tilstandsbasert brannmur som avslår svaret, loggar eit dropp; ein tilstandslaus kant avslår det stille, og difor går verten rett og slett i tidsavbrot.

Bygg løyvet rundt protokollen, ikkje eit portnummer

Avgrens regelen til dei faktiske adressene til resolvaren, målverten og mottaksport-politikken som produktet støttar. Hugs òg TCP-vegen til DNS, fordi eit stort svar eller eit tilbakefall ved trunkering flyttar utvekslinga til TCP, og ein regel berre for UDP dekkjer henne ikkje. Om kanten støttar tilstandsbasert inspeksjon for ein definert straum, føretrekk det framfor ein handskriven svarregel, fordi den tilstandsbaserte vegen følgjer portane klienten vel automatisk.

Stadfest deretter kva produkt i banen som faktisk filtrerer trafikken. Eit dokumentert IPv4-kantområde etablerer ikkje ein IPv6-politikk, og leverandørintern trafikk går kanskje aldri gjennom det same filteret.

Kvifor det ikkje er ei løysing å tillate ein kvar kjeldeport 53

Ein regel som godtar alt som hevdar å ha kjeldeport 53, er ein regel som godtar det ein avsendar skriv i eit headerfelt. Portnummeret autentiserer ikkje avsendaren og beviser ikkje at nyttelasta er eit gyldig svar, så regelen aukar eksponeringa til verten utan å gjere oppslaget meir påliteleg. Hald på kjeldeavgrensingar og hald på klienten sine eigne svarkontrollar, inkludert randomisering av kjeldeport, i staden for å slå dei av for å forenkle ei tilgangsliste.

Om resolvaren er ei teneste du kontrollerer, er det nok å avgrense til adressene hennar. Om han er ein offentleg resolvar, avgrens til adressene du har godkjent, og noter dei i kommentaren til regelen.

Verifiser ved rett grense, i rett retning

Tak opp på verten og ved kanten for den same spurnaden, og samanlikn tuppela i staden for pakketeljingane. Ein spurnad som er synleg på båe sider utan eit svar synleg på vertssida, peikar på det innkomande filteret; ein spurnad som berre er synleg på vertssida, peikar på ruting eller resolvaren sjølv. Gjenta med ein TCP-spurnad om du berre har løyve for UDP, fordi det er holet den fyrste testen ikkje kan sjå.

Å rette dette fullfører ei DNS-utveksling som verten verkeleg treng. Det gjer ikkje verten til ein offentleg resolvar, tillèt ikkje vidaresende VPN-straumar og beviser ikkje at DNS var årsaka til eit eller anna urelatert tunnelproblem.