Súkromné DNS meno alebo len IP? Rozhodnite skôr, než ho zdieľate

Dve otázky sa miešajú, keď sa súkromná služba otvára vzdialeným používateľom. Prvá je, aké meno majú klienti používať; druhá, ktoré zdroje má služba prijímať. Odpovedzte v tomto poradí, pretože správne meno za nesprávnym pravidlom prístupu stále zlyhá a správne pravidlo za menom, ktoré sa nerozlišuje, sa nikdy netestuje.

Podmienka prvá: akú cestu rezolvera majú klienti?

Súkromné meno funguje len vtedy, ak naň rezolver klienta dokáže odpovedať. Znamená to, že autorizovaný vzdialený klient musí dosiahnuť DNS server, ktorý drží zónu, buď cez tunel, alebo cez rezolver, ktorý organizácia už prevádzkuje pre vzdialených používateľov. Tunel je transport, nie adresár. Dáva klientovi cestu k rezolveru a nehovorí mu, na ktorú zónu sa má pýtať.

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

Verejný rezolver sa súkromnú zónu nedozvie len preto, že sa notebook pripojil k VPN.

Prípona si zaslúži rovnakú pozornosť. Použite subdoménu domény, ktorú organizácia ovláda, aby vlastníctvo a plánovanie certifikátov zostali jasné. Vyhnite sa .local: špecifikácia multicast DNS viaže túto príponu na link-local rozlišovanie a smerovaný tunel toto správanie za vás nezopakuje.

Podmienka druhá: ktorý zdroj služba dostáva?

Pravidlá prijatia sa píšu proti adresám, takže užitočná otázka je, ktorú adresu služba vidí po smerovaní a preklade. Pre ukážkovú službu na 10.20.30.40 prichádzajú kancelárski klienti z 10.20.30.0/24 a vzdialení klienti z oddeleného fondu, napríklad 10.99.0.0/24.

Ak brána prekladá vzdialený fond, služba vidí prekladač a pravidlo napísané pre 10.99.0.0/24 nebude sedieť.

Čítajte to zo strany služby, nie zo strany klienta. Protokol poslucháča alebo zachytenie paketov na hostiteľovi služby ukáže zdroj, ktorý skutočne dorazil; vlastná adresa klienta je len odhad toho, čo cestou prežilo.

Podmienka tretia: je meno viazané na službu alebo na hostiteľa?

Meno, ktoré ukazuje na adresu jedného stroja, viaže každého klienta na ten stroj. Meno, ktoré ukazuje na vyrovnávač záťaže alebo stabilnú adresu služby, prežije výmenu hostiteľa za ním. Vyberajte vedome, pretože neskoršia zmena znamená zmenu záložiek každého klienta a subjektu každého certifikátu.

Pre jednu internú službu je priamy záznam zvyčajne v poriadku a ľahšie sa o ňom uvažuje.

Pre všetko, čo bude vymenené, prestavané alebo škálované, stojí stabilný front za konfiguráciu navyše. Test je jednoduchý: ak môžete vymeniť backend bez informovania používateľov, meno je viazané na službu; ak nie, je viazané na hostiteľa.

Otestujte obe rozhodnutia oddelene

Najprv rozlíšte, potom sa pripojte. Test rozlíšenia, ktorý vráti očakávanú adresu, dokazuje cestu mena a nič nehovorí o prijatí. Test pripojenia dokazuje cestu aj pravidlo spolu, preto ho spustite až po úspešnom rozlíšení.

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

Potom raz otestujte zakázaný zdroj a výsledok zaznamenajte.

Držte oba záznamy oddelene v dokumentácii: meno a jeho zónu, prijímané zdroje a vlastníka pravidla. Keď sa jedno zmení, druhé nemusí.

Kde sa rozhodnutie zvyčajne pokazí

Častá porucha je služba publikovaná pod menom, ktoré sa rozlišuje len v kancelárskej sieti, s pravidlom prijatia, ktoré prijíma len kancelársky rozsah. Vzdialení používatelia potom hlásia pokazenú službu, ktorá sú v skutočnosti dve oddelené opomenutia. Druhá častá porucha je opak: široké pravidlo prijatia pridané, aby zmizol problém s menom, nechá službu dostupnú zo zdrojov, ktoré nikto nezamýšľal. Obe sú opomenutia v konfigurácii a z používateľovej stoličky vyzerajú rovnako.

Ani jednu chybu nevidno z jedného úspešného testu. Preto si obe rozhodnutia zaslúžia oddelené záznamy a oddelené testy, aj keď ich robí ten istý človek.

Zapíšte oboje pred uvedením služby do prevádzky, pretože ďalšia zmena sa bude ľahšie premýšľať. Záznam je krátky: jeden riadok pre meno a jeho zónu, jeden riadok pre prijímané zdroje a vlastníka pravidla.