Privata DNS-nomo aŭ nur IP-adreso? Decidu antaŭ ol kunhavigi ĝin

Du demandoj miksiĝas, kiam privata servo malfermiĝas al malproksimaj uzantoj. La unua estas, kiun nomon klientoj uzu; la dua estas, kiujn fontojn la servo akceptu. Respondu ilin en tiu ordo, ĉar ĝusta nomo malantaŭ malĝusta alirregulo ankoraŭ malsukcesas, kaj ĝusta regulo malantaŭ nomo, kiu ne solviĝas, neniam estas testata.

Kondiĉo unu: kiun solvilan vojon havas la klientoj?

Privata nomo funkcias nur se la solvilo de la kliento povas respondi ĝin. Tio signifas, ke rajtigita malproksima kliento devas atingi DNS-servilon, kiu tenas la zonon, ĉu tra la tunelo ĉu tra solvilo, kiun la organizo jam funkciigas por malproksimaj uzantoj. La tunelo estas transporto, ne adresaro. Ĝi donas al la kliento vojon al solvilo, kaj ĝi ne diras al ĝi, kiun zonon demandi.

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

Publika solvilo ne lernos privatan zonon tial, ke la tekkomputilo konektiĝis al VPN.

La sufikso meritas la saman atenton. Uzu subdomajnon de domajno, kiun la organizo kontrolas, por ke posedo kaj atestila planado restu klaraj. Evitu .local: la specifikaĵo de multdissenda DNS ligas tiun sufikson al link-local solvado, kaj enkursigita tunelo ne reproduktas tiun konduton por vi.

Kondiĉo du: kiun fonton ricevas la servo?

Alirreguloj estas skribataj kontraŭ adresoj, do la utila demando estas, kiun adreson la servo vidas post enkursigado kaj tradukado. Por ekzempla servo ĉe 10.20.30.40, oficejaj klientoj alvenas el 10.20.30.0/24 kaj malproksimaj klientoj el aparta aro kiel 10.99.0.0/24.

Se pordego tradukas la malproksiman aron, la servo vidas la tradukilon, kaj regulo skribita por 10.99.0.0/24 ne kongruos.

Legu tion de la flanko de la servo, ne de la flanko de la kliento. Protokolo de aŭskultanto aŭ paketa kapto sur la serva gastiganto montras la fonton, kiu fakte alvenis; la propra adreso de la kliento estas nur konjekto pri tio, kio postvivis la vojon.

Kondiĉo tri: ĉu la nomo ligiĝas al servo aŭ al gastiganto?

Nomo, kiu montras al adreso de unu maŝino, kunligas ĉiun klienton al tiu maŝino. Nomo, kiu montras al ŝarĝa distribuilo aŭ al stabila serva adreso, postvivas anstataŭigon de la gastiganto malantaŭ ĝi. Elektu konscie, ĉar ŝanĝi tion poste signifas ŝanĝi la legosignojn de ĉiu kliento kaj la subjekton de ĉiu atestilo.

Por unu interna servo, rekta rikordo kutime taŭgas kaj estas pli facila pripense.

Por io ajn, kio estos anstataŭigita, rekonstruita aŭ skalita, stabila fasado valoras la plian agordon. La testo estas simpla: se vi povas anstataŭigi la malantaŭon sen diri al la uzantoj, la nomo ligiĝas al la servo; se vi ne povas, ĝi ligiĝas al gastiganto.

Testu la du decidojn aparte

Unue solvu, poste konektu. Solva testo, kiu redonas la atendatan adreson, pruvas la nomvojon kaj diras nenion pri aliro. Konekta testo pruvas la vojon kaj la regulon kune, do rulu ĝin nur post sukceso de la solvado.

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

Poste testu malpermesitan fonton unufoje, kaj registru la rezulton.

Tenu la du rikordojn aparte en via dokumentaro: la nomo kaj ĝia zono, la akceptitaj fontoj kaj la posedanto de la regulo. Kiam unu ŝanĝiĝas, la alia ne devas.

Kie la decido kutime eraras

La kutima fiasko estas servo publikigita sub nomo, kiu solviĝas nur en la oficeja reto, kun alirregulo, kiu akceptas nur la oficejan gamon. Malproksimaj uzantoj tiam raportas rompitan servon, kiu fakte estas du apartaj preterlasoj. La dua kutima fiasko estas la malo: larĝa alirregulo aldonita por forigi nomproblemon lasas la servon atingebla el fontoj, kiujn neniu celis. Ambaŭ estas preterlasoj en agordo, kaj de la seĝo de la uzanto ili aspektas same.

Neniu el la eraroj videblas el unu sukcesa testo. Tial la du decidoj meritas apartajn rikordojn kaj apartajn testojn, eĉ kiam la sama persono faras ambaŭ.

Skribu ambaŭ antaŭ ol la servo eklaboros, ĉar la sekva ŝanĝo estos pli facila pripense. La rikordo estas mallonga: unu linio por la nomo kaj ĝia zono, unu linio por la akceptitaj fontoj kaj la posedanto de la regulo.