Tillåtelselista för VPN-slutpunkter: DNS-uppdateringen du glömde

Att skriva vpn.example.com i ett brandväggsundantag känns som att prenumerera på DNS. Det som vanligtvis händer är en översättning vid inläsning, varefter regeln håller adresser och ingenting uppdaterar dem. Två komponenter delar nu jobbet: resolvern som svarar och brandväggen som lagrar. De flesta slutpunktsavbrott börjar där den överlämningen aldrig designades.

Ett värdnamn i en regel är inte en levande prenumeration

Vissa verktyg löser ett namn när konfigurationen läses in; andra behåller ett värdnamn och löser det igen enligt sitt eget schema; ytterligare andra accepterar bara adresser. Den synliga konfigurationen anger sällan vilket. Dokumentationsexempel antar vanligtvis inläsningsfallet, vilket är varför skillnaden överraskar människor under en migrering. Läs implementationens beteende innan du antar att en adressändring märks, eftersom en inaktuell tillåtelselista ser exakt ut som en som fungerar tills slutpunkten flyttar.

En regel som namnger rätt värd kan fortfarande tillåta fel adress. Den luckan är myten, inte ett stavfel.

Cache-TTL är inte din brandväggs timer

DNS-poster har en livstid, och resolvers cachar svar under den perioden. DNS-specifikationen definierar det cachebeteendet, men den styr DNS-data, inte en brandväggs separata adresslager. En kort TTL skapar inte ett uppdateringsjobb där inget finns. Cachning sker också på mer än ett lager, så svaret en terminal ser är kanske inte det brandväggen såg.

Ställ tre frågor till den faktiska produkten: när den löser, var den lagrar resultatet och vad som utlöser en uppdatering. Om svaret bara gäller vid start kan en långvarig session överleva adressen den släpptes in till.

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

Designa uppdatering och fel som en enda policy

Ett underhållet undantag behöver uttryckliga svar: vad som utlöser en uppdatering innan klienten väljer en ny adress, hur den tillåtna uppsättningen ändras utan att öppna ett brett tillfälligt fönster och när inaktuella poster tas bort. Skriv svaren bredvid regeln.

Välj felbeteendet medvetet. Att behålla den gamla adressen kan rädda en session och lämna ett inaktuellt tillstånd; att tömma uppsättningen kan blockera återställning. Inget av dem bör vara ett oavsiktligt resultat av ett misslyckat uppslag. Skriv det valda beteendet i runbooken så att nästa operatör inte improviserar under press.

Håll också bootstrap-DNS smalt. Ett ovillkorligt undantag för en offentlig resolver är en direkt DNS-väg för allt det matchar, inte bara för slutpunktens namn.

Bevisa slutpunktsändringen, inte den första anslutningen

Använd klientens hanterare om den redan samordnar uppslagning och blockering. På en sajtadministrerad PF-värd, behåll sajtens ägarskap och återställningsplan i stället för att kopiera värdnamnstabellsyntax från en annan plattform med annat livscykelbeteende.

Med ett godkänt, ofarligt test, jämför adressen klienten väljer med den aktiva tillåtna uppsättningen före och efter en kontrollerad ändring. Täck ett misslyckat uppslag, borttagning av en post som inte längre är giltig och, där det stöds, en annan adressfamilj. Den avsedda tunneln bör återhämta sig medan orelaterad direkt trafik stannar under policyn. En lyckad första anslutning bevisar bara att den inledande översättningen råkade vara korrekt.