Tilladelsesliste til VPN-endepunkter: Den DNS-opdatering, du glemte

At skrive vpn.example.com ind i en firewall-undtagelse føles som at abonnere på DNS. Det, der normalt sker, er en oversættelse ved indlæsning, hvorefter reglen holder adresser og intet opdaterer dem. To komponenter deler nu arbejdet: resolvere, der svarer, og firewallen, der gemmer. De fleste endepunktsudfald starter, hvor den overlevering aldrig blev designet.

Et værtsnavn i en regel er ikke et levende abonnement

Nogle værktøjer slår et navn op, når konfigurationen indlæses; andre beholder et værtsnavn og slår det op igen efter deres egen tidsplan; andre igen accepterer kun adresser. Den synlige konfiguration siger sjældent hvilket. Dokumentationseksempler antager normalt indlæsningstilfældet, hvilket er grunden til, at forskellen overrasker folk under en migrering. Læs implementeringens adfærd, før du antager, at en adresseændring bliver bemærket, fordi en forældet tilladelsesliste ser nøjagtigt ud som en, der virker, indtil endepunktet flytter.

En regel, der navngiver den rigtige vært, kan stadig tillade den forkerte adresse. Det hul er myten, ikke en stavefejl.

Cache-TTL er ikke din firewalls timer

DNS-poster har en levetid, og resolvere cacher svar for den periode. DNS-specifikationen definerer den cacheadfærd, men den styrer DNS-data, ikke en firewalls separate adresselager. En kort TTL skaber ikke et opdateringsjob, hvor der ikke er noget. Caching sker også på mere end et lag, så det svar, en terminal ser, er måske ikke det, firewallen så.

Stil tre spørgsmål til det faktiske produkt: hvornår det slår op, hvor det gemmer resultatet, og hvad der udløser en opdatering. Hvis svaret kun er ved opstart, kan en langvarig session overleve den adresse, den blev lukket ind til.

dig +short vpn.example.com
resolvectl query vpn.example.com

Design opdatering og fejl som én politik

En vedligeholdt undtagelse kræver eksplicitte svar: hvad udløser en opdatering, før klienten vælger en ny adresse, hvordan det tilladte sæt ændres uden at åbne et bredt midlertidigt vindue, og hvornår forældede poster fjernes. Skriv svarene ved siden af reglen.

Vælg fejladfærden bevidst. At beholde den gamle adresse kan bevare en session og efterlade en forældet tilladelse; at rydde sættet kan spærre gendannelse. Ingen af dem bør være et tilfældigt resultat af et mislykket opslag. Skriv den valgte adfærd i runbooken, så den næste operatør ikke improviserer under pres.

Hold også bootstrap-DNS smal. En ubetinget offentlig resolver-undtagelse er en direkte DNS-vej for alt, den matcher, ikke kun for endepunktets navn.

Bevis endepunktsændringen, ikke den første forbindelse

Brug klientens understøttede manager, hvis den allerede koordinerer opløsning og blokering. På en siteadministreret PF-vært skal du beholde stedets ejerskab og gendannelsesplan i stedet for at kopiere værtsnavnetabel-syntaks fra en anden platform med anderledes livscyklusadfærd.

Med en godkendt, ufarlig test skal du sammenligne den adresse, klienten vælger, med det aktive tilladte sæt før og efter en kontrolleret ændring. Dæk et mislykket opslag, sletning af en post, der ikke længere er gyldig, og, hvor det understøttes, en anden adressefamilie. Den tilsigtede tunnel skal komme sig, mens uafhængig direkte trafik forbliver under politikken. En vellykket første forbindelse beviser kun, at den indledende oversættelse tilfældigvis var korrekt.