Lista de permisiuni a punctelor finale VPN: actualizarea DNS pe care ai uitat-o

Tastarea vpn.example.com într-o excepție de firewall pare o abonare la DNS. De obicei are loc o traducere la încărcare, după care regula păstrează adrese și nimic nu le actualizează. Două componente împart acum munca: resolverul care răspunde și firewallul care stochează. Majoritatea întreruperilor punctelor finale încep acolo unde această predare nu a fost niciodată proiectată.

Un nume de gazdă într-o regulă nu este un abonament activ

Unele instrumente rezolvă un nume la încărcarea configurației; altele păstrează un nume de gazdă și îl rezolvă din nou după propriul program; altele acceptă doar adrese. Configurația vizibilă spune rareori care. Exemplele din documentație presupun de obicei cazul încărcării, motiv pentru care diferența surprinde oamenii în timpul unei migrări. Citește comportamentul implementării înainte de a presupune că o schimbare de adresă va fi observată, deoarece o listă de permisiuni învechită arată exact ca una care funcționează până când punctul final se mută.

O regulă care numește gazda corectă poate permite totuși adresa greșită. Acea lacună este mitul, nu o greșeală de ortografie.

TTL-ul cache-ului nu este temporizatorul firewallului tău

Înregistrările DNS au o durată de viață, iar resolverele stochează în cache răspunsurile pentru acea perioadă. Specificația DNS definește acel comportament de cache, dar guvernează datele DNS, nu depozitul separat de adrese al unui firewall. Un TTL scurt nu creează o sarcină de actualizare acolo unde nu există. Cache-ul are loc și pe mai mult de un strat, așa că răspunsul văzut de un terminal poate să nu fie cel văzut de firewall.

Pune produsului real trei întrebări: când rezolvă, unde stochează rezultatul și ce declanșează o actualizare. Dacă răspunsul este doar la pornire, o sesiune de lungă durată poate supraviețui adresei la care a fost admisă.

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

Proiectează actualizarea și eșecul ca o singură politică

O excepție întreținută are nevoie de răspunsuri explicite: ce declanșează o actualizare înainte ca clientul să aleagă o adresă nouă, cum se schimbă setul permis fără a deschide o fereastră temporară largă și când sunt eliminate intrările învechite. Scrie acele răspunsuri lângă regulă.

Alege comportamentul la eșec în mod deliberat. Păstrarea adresei vechi poate conserva o sesiune și lăsa o permisiune învechită; golirea setului poate bloca recuperarea. Niciunul nu ar trebui să fie un rezultat accidental al unei căutări eșuate. Scrie comportamentul ales în runbook, ca următorul operator să nu improvizeze sub presiune.

Păstrează îngust și DNS-ul de pornire. O excepție necondiționată pentru un resolver public este o cale DNS directă pentru tot ce se potrivește, nu doar pentru numele punctului final.

Dovedește schimbarea punctului final, nu prima conexiune

Folosește managerul acceptat al clientului dacă acesta coordonează deja rezolvarea și blocarea. Pe un gazdă PF administrată de site, păstrează proprietatea și planul de recuperare ale site-ului în loc să copiezi sintaxa tabelului de nume de gazdă de pe altă platformă cu alt comportament al ciclului de viață.

Cu un test aprobat și inofensiv, compară adresa pe care clientul o selectează cu setul permis activ înainte și după o schimbare controlată. Acoperă o căutare eșuată, ștergerea unei intrări care nu mai este validă și, unde este acceptat, o altă familie de adrese. Tunelul dorit ar trebui să se recupereze, în timp ce traficul direct nelegat rămâne sub politică. O primă conexiune reușită dovedește doar că traducerea inițială a fost corectă din întâmplare.