Privaat DNS-naam of net 'n IP? Besluit voordat jy dit deel

Twee vrae raak deurmekaar wanneer 'n privaat diens vir afstandgebruikers oopgemaak word. Die eerste is watter naam kliënte moet gebruik; die tweede is watter bronne die diens moet toelaat. Beantwoord hulle in daardie volgorde, want 'n korrekte naam agter die verkeerde toegangsreël misluk steeds, en 'n korrekte reël agter 'n naam wat nie oplos nie, word nooit getoets nie.

Voorwaarde een: watter resolver-pad het kliënte?

’n Privaat naam werk net as die kliënt se resolver dit kan beantwoord. Dit beteken ’n gemagtigde afstandkliënt moet ’n DNS-bediener bereik wat die sone hou, hetsy deur die tonnel of deur ’n resolver wat die organisasie reeds vir afstandgebruikers bedryf. Die tonnel is ’n vervoermiddel, nie ’n gids nie. Dit gee die kliënt ’n pad na ’n resolver, en dit sê nie vir die kliënt watter sone om te vra nie.

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

’n Openbare resolver sal nie ’n privaat sone leer ken omdat die skootrekenaar aan ’n VPN gekoppel is nie.

Die agtervoegsel verdien dieselfde aandag. Gebruik ’n subdomein van ’n domein wat die organisasie beheer, sodat eienaarskap en sertifikaatbeplanning duidelik bly. Vermy .local: die multicast-DNS-spesifikasie bind daardie agtervoegsel aan skakel-plaaslike resolusie, en ’n gerouteerde tonnel reproduseer nie daardie gedrag vir jou nie.

Voorwaarde twee: watter bron ontvang die diens?

Toelatingsreëls word teen adresse geskryf, so die nuttige vraag is watter adres die diens sien ná routing en vertaling. Vir ’n voorbeelddiens by 10.20.30.40 kom kantoorkliënte van 10.20.30.0/24 en afstandkliënte van ’n aparte poel soos 10.99.0.0/24.

As ’n poort die afstandpoel vertaal, sien die diens die vertaler, en ’n reël wat vir 10.99.0.0/24 geskryf is, sal nie pas nie.

Lees dit van die dienskant eerder as die kliëntkant. ’n Luisteraar-log of ’n pakketopname op die diensgasheer wys die bron wat werklik aangekom het; die kliënt se eie adres is net ’n raaiskoot oor wat die pad oorleef het.

Voorwaarde drie: is die naam aan ’n diens of aan ’n gasheer gekoppel?

’n Naam wat na een masjien se adres wys, koppel elke kliënt aan daardie masjien. ’n Naam wat na ’n lasbalanseerder of ’n stabiele diensadres wys, oorleef die vervanging van die gasheer daaronder. Kies doelbewus, want om dit later te verander beteken om elke kliënt se boekmerke en elke sertifikaat se subjek te verander.

Vir ’n enkele interne diens is ’n direkte rekord gewoonlik goed en eenvoudiger om oor te redeneer.

Vir alles wat vervang, herbou of geskaal sal word, is ’n stabiele voorkant die ekstra konfigurasie werd. Die toets is eenvoudig: as jy die agterkant kan vervang sonder om gebruikers in te lig, is die naam aan die diens gekoppel; as jy dit nie kan nie, is dit aan ’n gasheer gekoppel.

Toets die twee besluite afsonderlik

Los eers op, dan verbind. ’n Resolusietoets wat die verwagte adres teruggee, bewys die naampad en sê niks oor toelating nie. ’n Verbindingstoets bewys die pad en die reël saam, so voer dit eers uit nadat resolusie geslaag het.

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

Toets dan een keer ’n verbode bron, en teken die resultaat aan.

Hou die twee rekords apart in jou dokumentasie: die naam en sy sone, die toegelate bronne en die eienaar van die reël. Wanneer een verander, hoef die ander nie.

Waar die besluit gewoonlik verkeerd loop

Die algemene fout is ’n diens wat onder ’n naam gepubliseer word wat net op die kantoornetwerk oplos, met ’n toelatingsreël wat net die kantoorreeks toelaat. Afstandgebruikers rapporteer dan ’n stukkende diens wat in werklikheid twee aparte weglatings is. Die tweede algemene fout is die omgekeerde: ’n wye toelatingsreël wat bygevoeg is om ’n naamprobleem weg te laat gaan, wat die diens bereikbaar laat van bronne wat niemand bedoel het nie. Albei is konfigurasieweglatings, en uit die gebruiker se stoel lyk hulle dieselfde.

Nie een van die foute is uit ’n enkele suksesvolle toets sigbaar nie. Daarom verdien die twee besluite aparte rekords en aparte toetse, selfs wanneer dieselfde persoon albei maak.

Skryf albei neer voordat die diens in bedryf gaan, want die volgende verandering sal makliker wees om oor te redeneer. Die rekord is kort: een reël vir die naam en sy sone, een reël vir die toegelate bronne en die eienaar van die reël.