Tillatelsesliste for VPN-endepunkter: DNS-oppdateringen du glemte
Et brannmur-unntak for et VPN-vertsnavn er ikke et levende DNS-abonnement. Bestem hvem som slår det opp, når settet oppdateres og hva et mislykket oppslag skal gjøre.
Å skrive vpn.example.com inn i et brannmur-unntak føles som å abonnere på DNS. Det som vanligvis skjer, er en oversettelse ved innlasting, hvoretter regelen holder adresser og ingenting oppdaterer dem. To komponenter deler nå jobben: resolvereen som svarer og brannmuren som lagrer. De fleste endepunktsavbrudd starter der denne overleveringen aldri ble designet.
Et vertsnavn i en regel er ikke et levende abonnement
Noen verktøy slår opp et navn når konfigurasjonen lastes; andre beholder et vertsnavn og slår det opp på nytt etter egen tidsplan; andre igjen godtar bare adresser. Den synlige konfigurasjonen sier sjelden hvilken. Dokumentasjonseksempler antar vanligvis innlastingstilfellet, og derfor overrasker forskjellen folk under en migrering. Les implementasjonens oppførsel før du antar at en adresseendring blir lagt merke til, fordi en utdatert tillatelsesliste ser nøyaktig ut som en som virker til endepunktet flytter seg.
En regel som navngir riktig vert, kan fortsatt tillate feil adresse. Det gapet er myten, ikke en skrivefeil.
Cache-TTL er ikke brannmurens tidtaker
DNS-poster har en levetid, og resolvere cacher svar for den perioden. DNS-spesifikasjonen definerer den cacheoppførselen, men den styrer DNS-data, ikke en brannmurs separate adresselager. En kort TTL lager ikke en oppdateringsjobb der ingen finnes. Cache lagres også på mer enn ett lag, så svaret en terminal ser er kanskje ikke det brannmuren så.
Still tre spørsmål til det faktiske produktet: når det slår opp, hvor det lagrer resultatet, og hva som utløser en oppdatering. Hvis svaret bare er ved oppstart, kan en langvarig økt overleve adressen den ble sluppet inn til.
dig +short vpn.example.com
resolvectl query vpn.example.com
Design oppdatering og feil som én policy
Et vedlikeholdt unntak trenger eksplisitte svar: hva som utløser en oppdatering før klienten velger en ny adresse, hvordan det tillatte settet endres uten å åpne et bredt midlertidig vindu, og når utdaterte oppføringer fjernes. Skriv svarene ved siden av regelen.
Velg feiloppførselen bevisst. Å beholde den gamle adressen kan bevare en økt og etterlate en utdatert tillatelse; å tømme settet kan blokkere gjenoppretting. Ingen av dem bør være et tilfeldig resultat av et mislykket oppslag. Skriv den valgte oppførselen i runbooken slik at neste operatør ikke improviserer under press.
Hold også oppstarts-DNS smalt. Et ubetinget unntak for en offentlig resolver er en direkte DNS-vei for alt det treffer, ikke bare for endepunktets navn.
Bevis endepunktsendringen, ikke den første tilkoblingen
Bruk klientens støttede behandler hvis den allerede koordinerer oppslag og blokkering. På en nettstedsadministrert PF-vert, behold nettstedets eierskap og gjenopprettingsplan i stedet for å kopiere vertsnavntabellsyntaks fra en annen plattform med annen livssyklusoppførsel.
Med en godkjent, ufarlig test, sammenlign adressen klienten velger med det aktive tillatte settet før og etter en kontrollert endring. Dekk et mislykket oppslag, sletting av en oppføring som ikke lenger er gyldig og, der det støttes, en annen adressefamilie. Den tiltenkte tunnelen skal gjenopprettes mens uavhengig direkte trafikk forblir under policyen. En vellykket første tilkobling beviser bare at den første oversettelsen tilfeldigvis var riktig.