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

Dva pitanja se pomiješaju kada se privatna usluga otvori za udaljene korisnike. Prvo je koje ime klijenti treba da koriste; drugo je koje izvore usluga treba da prihvati. 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.

Uslov prvi: koji put rezolvera klijenti imaju?

Privatno ime radi samo ako rezolver klijenta može da odgovori na njega. To znači da autorizovani udaljeni klijent mora da dosegne DNS server koji drži zonu, bilo kroz tunel bilo kroz rezolver koji organizacija već vodi za udaljene korisnike. Tunel je transport, a ne imenik. On daje klijentu put do rezolvera i ne govori mu koju zonu da pita.

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 laptop povezan na VPN.

Sufiks zaslužuje istu pažnju. Koristite poddomenu domena koji organizacija kontroliše, da vlasništvo i planiranje certifikata ostanu eksplicitni. Izbjegavajte .local: specifikacija multicast DNS-a veže taj sufiks za link-local razrješavanje, a rutirani tunel ne reprodukuje to ponašanje za vas.

Uslov drugi: koji izvor usluga prima?

Pravila prihvatanja se pišu prema adresama, pa je korisno pitanje koju adresu usluga vidi nakon rutiranja i prevođenja. Za primjer usluge na 10.20.30.40, uredski klijenti dolaze sa 10.20.30.0/24, a udaljeni klijenti iz odvojenog pula kao što je 10.99.0.0/24.

Ako gateway prevede udaljeni pul, usluga vidi prevodioca, 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šaoca ili snimka paketa na hostu usluge pokazuje izvor koji je zaista stigao; vlastita adresa klijenta je samo nagađanje o tome šta je preživjelo put.

Uslov treći: je li ime vezano za uslugu ili za host?

Ime koje pokazuje na adresu jedne mašine vezuje svakog klijenta za tu mašinu. 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, direktan zapis je obično 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 za uslugu; ako ne možete, vezano je za 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 prihvatanju. 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 naopako

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

Nijedna greš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 red za ime i njegovu zonu, jedan red za prihvaćene izvore i vlasnika pravila.