Soukromé DNS jméno, nebo jen IP adresa? Rozhodněte dřív, než ho nasdílíte

Dvě otázky se míchají, když se soukromá služba otevírá vzdáleným uživatelům. První je, jaké jméno mají klienti používat; druhá, které zdroje má služba přijímat. Odpovězte v tomto pořadí, protože správné jméno za špatným pravidlem přístupu stejně selže a správné pravidlo za jménem, které se neřeší, se nikdy neotestuje.

Podmínka první: jakou cestu rezolveru klienti mají?

Soukromé jméno funguje jen tehdy, když na něj rezolver klienta umí odpovědět. To znamená, že autorizovaný vzdálený klient musí dosáhnout DNS serveru, který drží zónu, buď přes tunel, nebo přes rezolver, který organizace už provozuje pro vzdálené uživatele. Tunel je transport, ne adresář. Dává klientovi cestu k rezolveru a neříká mu, na kterou zónu se má ptát.

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

Veřejný rezolver se soukromou zónu nedozví jen proto, že se notebook připojil k VPN.

Sufix si zaslouží stejnou pozornost. Použijte subdoménu domény, kterou organizace ovládá, aby vlastnictví a plánování certifikátů zůstaly zřejmé. Vyhněte se .local: specifikace multicast DNS váže tento sufix na link-local rozlišení a směrovaný tunel toto chování za vás nezopakuje.

Podmínka druhá: jaký zdroj služba dostává?

Pravidla přijetí se píší proti adresám, takže užitečná otázka je, jakou adresu služba vidí po směrování a překladu. Pro ukázkovou službu na 10.20.30.40 přicházejí kancelářští klienti z 10.20.30.0/24 a vzdálení klienti z odděleného poolu, například 10.99.0.0/24.

Pokud brána překládá vzdálený pool, služba vidí překladatele a pravidlo napsané pro 10.99.0.0/24 nebude odpovídat.

Čtěte to ze strany služby, ne ze strany klienta. Protokol posluchače nebo zachycení paketů na hostiteli služby ukáže zdroj, který skutečně dorazil; vlastní adresa klienta je jen odhad toho, co cestou přežilo.

Podmínka třetí: je jméno vázané na službu, nebo na hostitele?

Jméno, které ukazuje na adresu jednoho stroje, váže každého klienta na ten stroj. Jméno, které ukazuje na vyrovnavač zátěže nebo stabilní adresu služby, přežije výměnu hostitele za ním. Vybírejte vědomě, protože pozdější změna znamená změnit záložky každého klienta a subjekt každého certifikátu.

Pro jednu interní službu je přímý záznam obvykle v pořádku a snáze se o něm uvažuje.

Pro cokoli, co bude vyměněno, přestavěno nebo škálováno, stojí stabilní fronta za konfiguraci navíc. Test je jednoduchý: pokud můžete vyměnit backend, aniž byste o tom informovali uživatele, je jméno vázané na službu; pokud ne, je vázané na hostitele.

Otestujte obě rozhodnutí odděleně

Nejprve vyřešte, potom se připojte. Test rozlišení, který vrátí očekávanou adresu, dokazuje cestu jména a nic neříká o přijetí. Test připojení dokazuje cestu i pravidlo zároveň, takže jej spusťte až po úspěšném rozlišení.

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

Potom jednou otestujte zakázaný zdroj a výsledek zaznamenejte.

Držte oba záznamy oddělené v dokumentaci: jméno a jeho zónu, přijímané zdroje a vlastníka pravidla. Když se jedno změní, druhé nemusí.

Kde se rozhodnutí obvykle pokazí

Častá porucha je služba publikovaná pod jménem, které se řeší jen v kancelářské síti, s pravidlem přijetí, které přijímá jen kancelářský rozsah. Vzdálení uživatelé pak hlásí rozbitou službu, která jsou ve skutečnosti dvě oddělená opomenutí. Druhá častá porucha je opak: široké pravidlo přijetí přidané, aby zmizel problém se jménem, nechá službu dostupnou ze zdrojů, které nikdo nezamýšlel. Obě jsou opomenutí v konfiguraci a z uživatelova pohledu vypadají stejně.

Ani jednu chybu není vidět z jednoho úspěšného testu. Proto si obě rozhodnutí zaslouží oddělené záznamy a oddělené testy, i když je činí stejný člověk.

Zapište obojí dřív, než služba půjde do provozu, protože další změna se bude snáze promýšlet. Záznam je krátký: jeden řádek pro jméno a jeho zónu, jeden řádek pro přijímané zdroje a vlastníka pravidla.