Nom DNS privat o només una IP? Decidiu-ho abans de compartir-lo

Dues preguntes es barregen quan un servei privat s'obre a usuaris remots. La primera és quin nom han de fer servir els clients; la segona, quines fonts ha d'admetre el servei. Responeu-les en aquest ordre, perquè un nom correcte darrere d'una regla d'admissió equivocada encara falla, i una regla correcta darrere d'un nom que no es resol no s'arriba a provar mai.

Condició primera: quin camí de resolutor tenen els clients?

Un nom privat només funciona si el resolutor del client el pot respondre. Això vol dir que un client remot autoritzat ha d'arribar a un servidor DNS que tingui la zona, ja sigui pel túnel o per un resolutor que l'organització ja executa per als usuaris remots. El túnel és un transport, no un directori. Dona al client un camí cap a un resolutor, i no li diu quina zona ha de preguntar.

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

Un resolutor públic no aprendrà una zona privada perquè l'ordinador portàtil s'hagi connectat a una VPN.

El sufix mereix la mateixa atenció. Feu servir un subdomini d'un domini que l'organització controli, perquè la propietat i la planificació de certificats quedin explícites. Eviteu .local: l'especificació de DNS multicast lliga aquest sufix a la resolució link-local, i un túnel encaminat no reprodueix aquest comportament per vosaltres.

Condició segona: quina font rep el servei?

Les regles d'admissió s'escriuen contra adreces, així que la pregunta útil és quina adreça veu el servei després de l'encaminament i la traducció. Per a un servei d'exemple a 10.20.30.40, els clients d'oficina arriben des de 10.20.30.0/24 i els clients remots des d'un conjunt separat com 10.99.0.0/24.

Si una passarel·la tradueix el conjunt remot, el servei veu el traductor, i una regla escrita per a 10.99.0.0/24 no coincidirà.

Llegiu-ho des del costat del servei i no des del costat del client. Un registre d'escolta o una captura de paquets a l'amfitrió del servei mostra la font que ha arribat realment; l'adreça del client només és una conjectura sobre què ha sobreviscut al camí.

Condició tercera: el nom està lligat a un servei o a un amfitrió?

Un nom que apunta a l'adreça d'una màquina lliga cada client a aquesta màquina. Un nom que apunta a un balancejador de càrrega o a una adreça de servei estable sobreviu a la substitució de l'amfitrió que hi ha darrere. Trieu-ho deliberadament, perquè canviar-ho més endavant significa canviar els marcadors de cada client i el subjecte de cada certificat.

Per a un sol servei intern, un registre directe sol ser adequat i més senzill de raonar.

Per a qualsevol cosa que es substituirà, es reconstruirà o s'escalarà, un frontal estable val la configuració extra. La prova és simple: si podeu substituir el backend sense avisar els usuaris, el nom està lligat al servei; si no, està lligat a un amfitrió.

Proveu les dues decisions per separat

Primer resoleu, després connecteu. Una prova de resolució que retorna l'adreça esperada demostra el camí del nom i no diu res sobre l'admissió. Una prova de connexió demostra el camí i la regla alhora, així que executeu-la només després que la resolució tingui èxit.

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

Després proveu una font prohibida una vegada i registreu el resultat.

Manteniu els dos registres separats a la documentació: el nom i la seva zona, les fonts admeses i el propietari de la regla. Quan un canvia, l'altre no cal.

On la decisió sol sortir malament

La fallada habitual és un servei publicat sota un nom que només es resol a la xarxa d'oficina, amb una regla d'admissió que només admet el rang d'oficina. Llavors els usuaris remots informen d'un servei trencat que en realitat són dues omissions separades. La segona fallada habitual és la inversa: una regla d'admissió àmplia afegida per fer desaparèixer un problema de nom deixa el servei abastable des de fonts que ningú no pretenia. Totes dues són omissions de configuració, i des de la cadira de l'usuari es veuen igual.

Cap de les dues errades no és visible des d'una sola prova correcta. Per això les dues decisions mereixen registres separats i proves separades, fins i tot quan les pren la mateixa persona.

Escriviu les dues coses abans que el servei entri en producció, perquè el proper canvi serà més fàcil de raonar. El registre és curt: una línia per al nom i la seva zona, una línia per a les fonts admeses i el propietari de la regla.