Tillatingsliste for VPN-endepunkt: DNS-oppdateringa du gløymde
Eit brannmur-unntak for eit VPN-vertnamn er ikkje eit levande DNS-abonnement. Avgjer kven som slår det opp, når settet oppdaterer seg og kva eit mislykka oppslag skal gjere.
Å skrive vpn.example.com inn i eit brannmur-unntak kjennest som å abonnere på DNS. Det som vanlegvis skjer, er ei omsetjing ved innlasting, og etterpå held regelen adresser og ingenting oppdaterer dei. To komponentar deler no jobben: resolvaren som svarar og brannmuren som lagrar. Dei fleste endepunktavbrot startar der denne overleveringa aldri vart designa.
Eit vertnamn i ei regel er ikkje eit levande abonnement
Nokre verktøy slår opp eit namn når konfigurasjonen lastar; andre held på eit vertnamn og slår det opp på nytt etter sin eigen tidsplan; andre igjen godtek berre adresser. Den synlege konfigurasjonen seier sjeldan kva. Dokumentasjonseksempel reknar vanlegvis med innlastingstilfellet, og difor overraskar skillnaden folk under ein migrasjon. Les åtferda til implementasjonen før du reknar med at ei adresseendring vert lagd merke til, fordi ei utdatert tillatingsliste ser nøyaktig ut som ei som verkar til endepunktet flyttar seg.
Ei regel som nemner rett vert, kan framleis tillate feil adresse. Det gapet er myten, ikkje ein skrivefeil.
Cache-TTL er ikkje tidtakararen til brannmuren din
DNS-postar har ei levetid, og resolvarar cachar svar for den perioden. DNS-spesifikasjonen definerer den cacheåtferda, men han styrer DNS-data, ikkje eit separat adresselager i ein brannmur. Ein kort TTL lagar ikkje ein oppdateringsjobb der ingen finst. Caching skjer òg på meir enn eitt lag, så svaret ein terminal ser er kanskje ikkje det brannmuren såg.
Still tre spørsmål til det faktiske produktet: når det slår opp, kvar det lagrar resultatet, og kva som utløyser ei oppdatering. Viss svaret berre er ved oppstart, kan ein langvarig økt overleve adressa ho vart sleppt inn til.
dig +short vpn.example.com
resolvectl query vpn.example.com
Design oppdatering og feil som éin policy
Eit vedlikehalde unntak treng eksplisitte svar: kva som utløyser ei oppdatering før klienten vel ei ny adresse, korleis det tillatne settet endrar seg utan å opne eit breitt mellombels vindauge, og når utdaterte oppføringar vert fjerna. Skriv svara ved sida av regelen.
Vel feilåtferda medvite. Å halde på den gamle adressa kan bevare ei økt og etterlate ei utdatert løyve; å tømme settet kan blokkere gjenoppretting. Ingen av dei bør vere eit tilfeldig resultat av eit mislykka oppslag. Skriv den valde åtferda i runbooken slik at neste operatør ikkje improviserer under press.
Hald òg oppstarts-DNS smalt. Eit vilkårslaust unntak for ein offentleg resolvar er ein direkte DNS-veg for alt det treffer, ikkje berre for namnet til endepunktet.
Prov endepunktendringa, ikkje den første tilkoplinga
Bruk den støtta behandlaren til klienten viss han alt koordinerer oppslag og blokkering. På ein nettstadadministrert PF-vert, hald på eigarskapen og gjenopprettingsplanen til nettstaden i staden for å kopiere vertnamntabellsyntaks frå ein annan plattform med annan livssyklusåtferd.
Med ein godkjend, ufarleg test, samanlikn adressa klienten vel med det aktive tillatne settet før og etter ei kontrollert endring. Dekk eit mislykka oppslag, sletting av ei oppføring som ikkje lenger er gyldig og, der det er støtta, ein annan adressefamilie. Den tiltenkte tunnelen skal gjenopprettast medan uavhengig direkte trafikk blir verande under policyen. Ei vellukka første tilkopling beviser berre at den første omsetjinga tilfeldigvis var riktig.