Privatno DNS ime ili samo IP? Odlučite prije nego što ga podijelite

Dva se pitanja pomiješaju kada se privatna usluga otvori za udaljene korisnike. Prvo je koje ime klijenti trebaju koristiti; drugo je koje izvore usluga treba prihvatiti. Odgovorite na njih tim redom, jer ispravno ime iza pogrešnog pravila pristupa i dalje pada, a ispravno pravilo iza imena koje se ne razrješava nikada se ne testira.

Uvjet prvi: koji put rezolvera klijenti imaju?

Privatno ime radi samo ako rezolver klijenta može odgovoriti na njega. To znači da autorizirani udaljeni klijent mora dosegnuti DNS poslužitelj koji drži zonu, bilo kroz tunel bilo kroz rezolver koji organizacija već vodi za udaljene korisnike. Tunel je prijevoz, a ne imenik. Daje klijentu put do rezolvera i ne govori mu koju zonu pitati.

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

Javni rezolver neće naučiti privatnu zonu zato što je prijenosnik povezan na VPN.

Sufiks zaslužuje jednaku pozornost. Koristite poddomenu domene koju organizacija kontrolira, da vlasništvo i planiranje certifikata ostanu eksplicitni. Izbjegavajte .local: specifikacija multicast DNS-a veže taj sufiks uz link-local razrješavanje, a usmjereni tunel ne reproducira to ponašanje za vas.

Uvjet drugi: koji izvor usluga prima?

Pravila prihvata pišu se prema adresama, pa je korisno pitanje koju adresu usluga vidi nakon usmjeravanja i prevođenja. Za primjer usluge na 10.20.30.40, uredski klijenti dolaze s 10.20.30.0/24, a udaljeni klijenti iz zasebnog skupa kao što je 10.99.0.0/24.

Ako pristupnik prevede udaljeni skup, usluga vidi prevoditelja, i pravilo napisano za 10.99.0.0/24 neće se poklopiti.

Čitajte ovo sa strane usluge, a ne sa strane klijenta. Dnevnik slušatelja ili snimka paketa na hostu usluge pokazuje izvor koji je doista stigao; vlastita adresa klijenta samo je nagađanje o tome što je preživjelo put.

Uvjet treći: je li ime vezano uz uslugu ili uz host?

Ime koje pokazuje na adresu jednog stroja veže svakog klijenta uz taj stroj. Ime koje pokazuje na balanser opterećenja ili stabilnu adresu usluge preživljava zamjenu hosta iza sebe. Odaberite svjesno, jer kasnija promjena znači mijenjanje oznaka svakog klijenta i subjekta svakog certifikata.

Za jednu internu uslugu izravan zapis obično je dobar i lakši za razmišljanje.

Za sve što će biti zamijenjeno, obnovljeno ili skalirano, stabilan front end vrijedi dodatne konfiguracije. Test je jednostavan: ako možete zamijeniti backend bez obavještavanja korisnika, ime je vezano uz uslugu; ako ne možete, vezano je uz host.

Testirajte dvije odluke odvojeno

Prvo razriješite, zatim se povežite. Test razrješavanja koji vraća očekivanu adresu dokazuje put imena i ne govori ništa o prihvatu. Test veze dokazuje put i pravilo zajedno, pa ga pokrenite tek nakon uspješnog razrješavanja.

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

Zatim jednom testirajte zabranjeni izvor i zabilježite rezultat.

Držite dva zapisa odvojeno u dokumentaciji: ime i njegovu zonu, prihvaćene izvore i vlasnika pravila. Kada se jedno promijeni, drugo ne mora.

Gdje odluka obično pođe po zlu

Čest kvar je usluga objavljena pod imenom koje se razrješava samo na uredskoj mreži, uz pravilo prihvata koje prihvaća samo uredski raspon. Udaljeni korisnici tada prijavljuju pokvarenu uslugu koja je zapravo dva odvojena propusta. Drugi čest kvar je obrnut: široko pravilo prihvata dodano da ukloni problem s imenom ostavlja uslugu dostupnom s izvora koje nitko nije namjeravao. Oba su propusti u konfiguraciji, i s korisničke stolice izgledaju isto.

Nijedna pogreška nije vidljiva iz jednog uspješnog testa. Zato dvije odluke zaslužuju odvojene zapise i odvojene testove, čak i kada ih donosi ista osoba.

Zapišite oboje prije nego usluga zaživi, jer će sljedeća promjena biti lakša za razmišljanje. Zapis je kratak: jedan redak za ime i njegovu zonu, jedan redak za prihvaćene izvore i vlasnika pravila.