Waarom het DNS-antwoord faalt bij een staatloze VPN-randfirewall

De tunnel staat, clients bereiken de VPN-host, en de host kan niets oplossen. Zijn eigen uitgaande query's verlaten de interface netjes, dus de fout zit op de terugweg: bij een bovenliggende rand die inkomend verkeer filtert zonder te onthouden wat de host zojuist heeft gestuurd. De tunnelpoort toestaan beschrijft die uitwisseling helemaal niet. Het antwoord op een DNS-query is een aparte stroom, en als de rand staatloos is, heeft niets hem toestemming gegeven om terug te keren.

De twee uitwisselingen zijn niet dezelfde uitwisseling

Schrijf de tuples op en de fout wordt duidelijk. De bestemmingspoort van het verzoek wordt de bronpoort van het antwoord, wat het tegenovergestelde is van wat de meeste mensen zich voorstellen als ze een inkomende regel voor poort 53 toevoegen:

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

Een inkomende regel die bestemmingspoort 53 vereist, beschrijft verkeer dat gericht is aan een DNS-listener die op de host draait, en dat is een heel andere dienst. Die adressen zijn documentatievoorbeelden, en de bronpoort wordt per query door de client gekozen, dus het is geen waarde die je in een regel kunt kopiëren en kunt verwachten dat die blijft werken.

Staatloze rand versus stateful host-firewall

Een staatloos randfilter beoordeelt elk inkomend pakket tegen zijn regellijst zonder een verbindingstabel erachter. Een uitgaande query die er goed uitging, schept geen toestemming voor het bijbehorende inkomende antwoord, omdat het apparaat geen registratie heeft dat er ooit een query was. Een stateful host-firewall is het omgekeerde: de verbindingstracking herkent het retourverkeer van een toegestane uitwisseling en laat het door zonder regel voor het antwoord. Beide grenzen bestaan in een typisch pad, en beide moeten het bedoelde pakket toestaan.

De vergelijking is belangrijk omdat de twee apparaten verschillend falen. Een stateful firewall die het antwoord weigert, logt een drop; een staatloze rand weigert het stil, waardoor de host simpelweg in een time-out loopt.

Bouw de toestemming rond het protocol, niet om een poortnummer

Beperk de regel tot de echte resolveradressen, de bestemmingshost en het beleid voor de ontvangende poort dat het product ondersteunt. Houd ook het TCP-pad van DNS in gedachten, want een groot antwoord of een terugval door afkapping verplaatst de uitwisseling naar TCP en een regel alleen voor UDP dekt dat niet. Als de rand stateful inspectie voor een gedefinieerde stroom ondersteunt, geef daar dan de voorkeur aan boven een handgeschreven antwoordregel, want het stateful pad volgt automatisch de poorten die de client kiest.

Bevestig daarna welk product in het pad het verkeer echt filtert. Een gedocumenteerd IPv4-randbereik legt geen IPv6-beleid vast, en providerintern verkeer gaat misschien nooit door diezelfde filter.

Waarom elke bronpoort 53 toestaan geen oplossing is

Een regel die alles accepteert wat beweert bronpoort 53 te hebben, is een regel die accepteert wat een afzender in een headerveld schrijft. Het poortnummer authenticeert de afzender niet en bewijst niet dat de payload een geldig antwoord is, dus de regel vergroot de blootstelling van de host zonder de resolutie betrouwbaarder te maken. Behoud bronbeperkingen en behoud de eigen antwoordcontroles van de client, inclusief randomisatie van de bronpoort, in plaats van ze uit te schakelen om een toegangslijst te vereenvoudigen.

Is de resolver een dienst die je beheert, dan volstaat beperking tot de adressen ervan. Is het een publieke resolver, beperk dan tot de adressen die je hebt goedgekeurd en noteer ze in het commentaar bij de regel.

Verifieer op de juiste grens, in de juiste richting

Leg op de host en bij de rand dezelfde query vast, en vergelijk de tuples in plaats van de pakkettingen. Een query die aan beide kanten zichtbaar is zonder antwoord aan de hostkant wijst op het inkomende filter; een query die alleen aan de hostkant zichtbaar is wijst op routing of de resolver zelf. Herhaal met een TCP-query als je alleen een UDP-toestemming hebt, want dat is precies het gat dat de eerste test niet kan zien.

Dit repareren voltooit een DNS-uitwisseling die de host echt nodig heeft. Het maakt de host geen publieke resolver, staat geen doorgestuurde VPN-stromen toe en bewijst niet dat DNS de oorzaak was van een of ander ongerelateerd tunnelprobleem.