Zasebno ime DNS ali samo IP? Odločite se, preden ga delite

Dve vprašanji se pomešata, ko se zasebna storitev odpre oddaljenim uporabnikom. Prvo je, katero ime naj uporabljajo odjemalci; drugo je, katere vire naj storitev dopusti. Odgovorite nanju v tem vrstnem redu, ker pravilno ime za napačnim pravilom dostopa vseeno ne uspe, pravilno pravilo za imenom, ki se ne razreši, pa ni nikoli preizkušeno.

Prvi pogoj: kakšno pot razreševalnika imajo odjemalci?

Zasebno ime deluje le, če lahko razreševalnik odjemalca odgovori nanj. To pomeni, da mora pooblaščeni oddaljeni odjemalec doseči strežnik DNS, ki hrani območje, bodisi skozi tunel bodisi skozi razreševalnik, ki ga organizacija že izvaja za oddaljene uporabnike. Tunel je prevoz, ne imenik. Odjemalcu da pot do razreševalnika in mu ne pove, katero območje naj vpraša.

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

Javni razreševalnik se zasebnega območja ne bo naučil zato, ker je prenosnik povezan z VPN.

Pripona si zasluži enako pozornost. Uporabite poddomeno domene, ki jo organizacija nadzoruje, da ostaneta lastništvo in načrtovanje potrdil jasna. Izogibajte se .local: specifikacija multicast DNS to pripono veže na razreševanje link-local, usmerjeni tunel pa tega vedenja ne ponovi namesto vas.

Drugi pogoj: kateri vir storitev prejme?

Pravila sprejema se pišejo glede na naslove, zato je koristno vprašanje, kateri naslov storitev vidi po usmerjanju in prevajanju. Za primer storitve na 10.20.30.40 prihajajo pisarniški odjemalci iz 10.20.30.0/24, oddaljeni odjemalci pa iz ločenega nabora, na primer 10.99.0.0/24.

Če prehod prevaja oddaljeni nabor, storitev vidi prevajalnika in pravilo, napisano za 10.99.0.0/24, se ne bo ujemalo.

Berite to s strani storitve in ne s strani odjemalca. Dnevnik poslušalca ali zajem paketov na gostitelju storitve pokaže vir, ki je v resnici prispel; naslov odjemalca samega je le ugibanje o tem, kaj je preživelo pot.

Tretji pogoj: je ime vezano na storitev ali na gostitelja?

Ime, ki kaže na naslov enega stroja, veže vsakega odjemalca na ta stroj. Ime, ki kaže na porazdeljevalnik obremenitve ali stabilen naslov storitve, preživi zamenjavo gostitelja za njim. Izberite zavestno, ker sprememba tega pozneje pomeni spremembo zaznamkov vsakega odjemalca in subjekta vsakega potrdila.

Za eno notranjo storitev je neposreden zapis običajno primeren in lažji za razmislek.

Za vse, kar bo zamenjano, obnovljeno ali skalirano, je stabilna sprednja stran vredna dodatne konfiguracije. Test je preprost: če lahko zamenjate zaledje, ne da bi obvestili uporabnike, je ime vezano na storitev; če ne morete, je vezano na gostitelja.

Preizkusite obe odločitvi ločeno

Najprej razrešite, nato se povežite. Test razreševanja, ki vrne pričakovani naslov, dokazuje pot imena in ne pove ničesar o sprejemu. Test povezave dokazuje pot in pravilo skupaj, zato ga zaženite šele po uspešnem razreševanju.

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

Nato enkrat preizkusite prepovedan vir in zapišite rezultat.

Držite oba zapisa ločeno v dokumentaciji: ime in njegovo območje, sprejete vire in lastnika pravila. Ko se eno spremeni, se drugo ne rabi.

Kje se odločitev običajno ponesreči

Pogosta okvara je storitev, objavljena pod imenom, ki se razreši le v pisarniškem omrežju, s pravilom sprejema, ki sprejme le pisarniški razpon. Oddaljeni uporabniki nato poročajo o pokvarjeni storitvi, ki je v resnici dve ločeni opustitvi. Druga pogosta okvara je obratna: široko pravilo sprejema, dodano, da bi izginil problem z imenom, pusti storitev dosegljivo iz virov, ki jih nihče ni nameraval. Obe sta opustitvi v konfiguraciji in s stola uporabnika sta videti enako.

Nobene napake ni videti iz enega uspešnega testa. Zato si obe odločitvi zaslužita ločena zapisa in ločena testa, tudi ko ju sprejme ista oseba.

Zapišite oboje, preden gre storitev v produkcijo, ker bo naslednjo spremembo lažje premisliti. Zapis je kratek: ena vrstica za ime in njegovo območje, ena vrstica za sprejete vire in lastnika pravila.