Nume DNS privat sau doar un IP? Decideți înainte de a-l partaja

Două întrebări se amestecă atunci când un serviciu privat este deschis utilizatorilor la distanță. Prima este ce nume ar trebui să folosească clienții; a doua este ce surse ar trebui să admită serviciul. Răspundeți-le în această ordine, pentru că un nume corect în spatele unei reguli de acces greșite tot eșuează, iar o regulă corectă în spatele unui nume care nu se rezolvă nu este niciodată testată.

Prima condiție: ce cale de resolver au clienții?

Un nume privat funcționează doar dacă resolverul clientului poate răspunde la acesta. Asta înseamnă că un client la distanță autorizat trebuie să ajungă la un server DNS care deține zona, fie prin tunel, fie printr-un resolver pe care organizația îl rulează deja pentru utilizatorii la distanță. Tunelul este un transport, nu un director. El îi dă clientului o cale către un resolver, și nu îi spune ce zonă să întrebe.

resolvectl query files.corp.example
dig @10.20.30.10 +short files.corp.example

Un resolver public nu va învăța o zonă privată pentru că laptopul s-a conectat la un VPN.

Sufixul merită aceeași atenție. Folosiți un subdomeniu al unui domeniu pe care organizația îl controlează, astfel încât proprietatea și planificarea certificatelor să rămână explicite. Evitați .local: specificația multicast DNS leagă acel sufix de rezolvarea link-local, iar un tunel rutat nu reproduce acel comportament pentru dumneavoastră.

A doua condiție: ce sursă primește serviciul?

Regulile de admitere sunt scrise față de adrese, așa că întrebarea utilă este ce adresă vede serviciul după rutare și traducere. Pentru un serviciu exemplu la 10.20.30.40, clienții din birou vin din 10.20.30.0/24, iar clienții la distanță dintr-un ansamblu separat precum 10.99.0.0/24.

Dacă un gateway traduce ansamblul de la distanță, serviciul vede traducătorul, iar o regulă scrisă pentru 10.99.0.0/24 nu se va potrivi.

Citiți asta din partea serviciului, nu din partea clientului. Un jurnal de ascultare sau o captură de pachete pe gazda serviciului arată sursa care a ajuns de fapt; adresa clientului însuși este doar o presupunere despre ce a supraviețuit pe cale.

A treia condiție: numele este legat de un serviciu sau de o gazdă?

Un nume care indică adresa unei singure mașini leagă fiecare client de acea mașină. Un nume care indică un echilibrator de încărcare sau o adresă de serviciu stabilă supraviețuiește înlocuirii gazdei din spatele lui. Alegeți deliberat, pentru că schimbarea asta mai târziu înseamnă schimbarea semnelor de carte ale fiecărui client și a subiectului fiecărui certificat.

Pentru un singur serviciu intern, o înregistrare directă este de obicei potrivită și mai ușor de gândit.

Pentru orice va fi înlocuit, reconstruit sau scalat, un front stabil merită configurația suplimentară. Testul este simplu: dacă puteți înlocui backendul fără să anunțați utilizatorii, numele este legat de serviciu; dacă nu, este legat de o gazdă.

Testați cele două decizii separat

Rezolvați mai întâi, apoi conectați. Un test de rezolvare care returnează adresa așteptată dovedește calea numelui și nu spune nimic despre admitere. Un test de conexiune dovedește calea și regula împreună, așa că rulați-l doar după ce rezolvarea reușește.

curl -sv --max-time 5 https://files.corp.example/health

Apoi testați o dată o sursă interzisă și notați rezultatul.

Țineți cele două înregistrări separate în documentație: numele și zona lui, sursele admise și proprietarul regulii. Când una se schimbă, cealaltă nu trebuie.

Unde merge de obicei greșit decizia

Defecțiunea obișnuită este un serviciu publicat sub un nume care se rezolvă doar în rețeaua biroului, cu o regulă de admitere care admite doar intervalul biroului. Utilizatorii la distanță raportează atunci un serviciu defect care în realitate este două omisiuni separate. A doua defecțiune obișnuită este inversul: o regulă de admitere largă adăugată pentru a elimina o problemă de nume lasă serviciul accesibil din surse pe care nimeni nu le-a intenționat. Ambele sunt omisiuni de configurare, iar din scaunul utilizatorului arată la fel.

Niciuna dintre greșeli nu este vizibilă dintr-un singur test reușit. De aceea cele două decizii merită înregistrări separate și teste separate, chiar și atunci când aceeași persoană le ia pe amândouă.

Scrieți-le pe amândouă înainte ca serviciul să intre în producție, pentru că următoarea schimbare va fi mai ușor de gândit. Înregistrarea este scurtă: o linie pentru nume și zona lui, o linie pentru sursele admise și proprietarul regulii.