Numele punctului final VPN versus numele unui serviciu privat: doi responsabili

Două nume pot descrie aceeași sucursală și pot răspunde la întrebări complet diferite. vpn.branch.example îi spune unui partener îndepărtat unde să găsească punctul final VPN, și trebuie rezolvat înainte de a exista orice tunel. inventory.branch.example îi spune unui utilizator autorizat unde locuiește o aplicație privată, și contează abia după ce tunelul este ridicat. Întreținerea unuia nu face nimic pentru celălalt.

Denumește ambele înregistrări înainte de a depana oricare dintre ele

Notează-le pe amândouă împreună cu responsabilii lor. Pentru punctul final, notează cine actualizează adresa publică și cum își reîmprospătează clientul VPN răspunsul. Pentru serviciu, notează cine deține adresa privată, ce zonă ține înregistrarea și ce resolveri ar trebui să răspundă pentru ea.

Acea listă scurtă previne cea mai frecventă diagnoză greșită din acest domeniu: repornirea unui tunel de sucursală funcțional pentru a repara o înregistrare care trăiește în întregime în interiorul lui. Tunelul este transportul pentru numele serviciului; nu este autoritatea lui.

Când se propune o schimbare, întreabă care dintre cele două înregistrări este atinsă. Dacă nimeni nu poate răspunde, schimbarea nu este gata de programare.

Punctul final trebuie rezolvat înainte de a exista orice tunel

Să presupunem că conexiunea la internet a sucursalei primește o nouă adresă publică. Actualizatorul punctului final publică noua adresă, iar implementarea VPN de la distanță trebuie să poată citi răspunsul modificat. Orice resolver care oferă acel răspuns trebuie să fie accesibil fără tunel, altfel clientul aleargă după un nume pe care îl poate rezolva doar după ce se conectează la ceea ce nu poate găsi.

Merită spusă clar această dependență de pornire, pentru că este ușor de creat din greșeală când toți resolverii interni stau în spatele VPN-ului. Păstrează o cale dinaintea tunelului pentru căutarea punctului final și confirmă comportamentul de reconectare al clientului în loc să presupui că un răspuns nou este preluat imediat.

DNS-ul dinamic are și limite pe care actualizarea înregistrării nu le poate trece. Actualizarea unei înregistrări nu deschide niciun port de firewall, nu creează nicio mapare NAT și nu dovedește nicio identitate de partener. O adresă publicată cu portul închis produce un client care rezolvă corect și tot nu se poate conecta la nimic.

În cele din urmă, un client în execuție poate continua să folosească un punct final din cache până când se reconectează. Separă în notele tale publicarea, cache-ul și politica de reconectare, ca un partener învechit să nu fie confundat cu un actualizator defect.

Numele serviciului descrie unde locuiește aplicația

Acum presupune că tunelul rămâne sănătos, dar serverul de inventar se mută de la 172.26.14.20 la 172.26.14.35. Înregistrarea publică a punctului final nu este afectată, în timp ce înregistrarea privată a serviciului trebuie schimbată. Folosirea unei adrese rezervate pentru acel serviciu, sau a unei alocări statice, face acest lucru mai rar; o cale de actualizare autorizată tratează cazurile când acest lucru este intenționat.

Aici se confundă două mecanisme de actualizare. RFC 2136 definește un protocol pentru adăugarea și ștergerea înregistrărilor DNS într-o zonă, în timp ce un furnizor comercial de DNS dinamic poate expune o API HTTP complet diferită pentru alt scop. Folosirea unuia nu implică faptul că celălalt există în mediul tău. Verifică ce mecanism acceptă de fapt zona ta înainte de a scrie un actualizator împotriva lui.

Un răspuns privat corect este doar prima condiție. Pentru ca un apelant de la distanță să îl folosească, clientul are nevoie de un resolver care transportă zona privată, de o politică ce permite interogări către acel resolver și de redirecționare pentru adresa care revine. Un nume care se rezolvă la o adresă pe care clientul nu o poate atinge produce un timp de așteptare care arată ca o defecțiune a serverului.

Testează cele două căi separat

Verifică punctul final din afara tunelului și serviciul din interior, și păstrează rezultatele ca două fapte independente:

$ dig +short vpn.branch.example @1.1.1.1
$ dig +short inventory.branch.example @172.26.0.53
$ ip route get 172.26.14.35

Dacă prima interogare eșuează, problema este publicarea publică sau calea de rezolvare dinaintea tunelului, și nicio schimbare internă nu va ajuta. Dacă a doua returnează o adresă dar a treia nu arată nicio rută prin tunel, stratul DNS este în regulă, iar politica de redirecționare nu.

Rulează perechea după fiecare schimbare de adresă și notează care înregistrare s-a mutat. O predare care spune doar „DNS a fost actualizat” lasă următorul inginer să ghicească care dintre cele două cicluri de viață a rulat de fapt.