Privat DNS-navn eller bare en IP? Bestem før du deler det
Velg navnet ut fra resolverstien, og tilgangsregelen ut fra kilden tjenesten ser. Det er to separate beslutninger, og hver har sin egen test.
To spørsmål blandes sammen når en privat tjeneste åpnes for eksterne brukere. Det første er hvilket navn klientene skal bruke; det andre er hvilke kilder tjenesten skal tillate. Svar på dem i den rekkefølgen, for et korrekt navn bak en feil tilgangsregel feiler fortsatt, og en korrekt regel bak et navn som ikke slås opp, blir aldri testet.
Betingelse én: hvilken resolversti har klientene?
Et privat navn virker bare hvis klientens resolver kan svare på det. Det betyr at en autorisert ekstern klient må nå en DNS-server som holder sonen, enten gjennom tunnelen eller gjennom en resolver organisasjonen allerede kjører for eksterne brukere. Tunnelen er en transport, ikke en katalog. Den gir klienten en sti til en resolver, og den forteller ikke klienten hvilken sone den skal spørre om.
resolvectl query files.corp.example
dig @10.20.30.10 +short files.corp.example
En offentlig resolver lærer ikke en privat sone fordi laptopen er koblet til en VPN.
Suffikset fortjener samme oppmerksomhet. Bruk et underdomene av et domene organisasjonen kontrollerer, slik at eierskap og sertifikatplanlegging forblir tydelige. Unngå .local: spesifikasjonen for multicast DNS binder det suffikset til link-local-oppslag, og en rutet tunnel gjenskaper ikke den oppførselen for deg.
Betingelse to: hvilken kilde mottar tjenesten?
Tilgangsregler skrives mot adresser, så det nyttige spørsmålet er hvilken adresse tjenesten ser etter ruting og oversettelse. For en eksempeltjeneste på 10.20.30.40 kommer kontorklienter fra 10.20.30.0/24 og eksterne klienter fra en egen pool som 10.99.0.0/24.
Hvis en gateway oversetter den eksterne poolen, ser tjenesten oversetteren, og en regel skrevet for 10.99.0.0/24 vil ikke stemme.
Les dette fra tjenestens side i stedet for klientens side. En lytterlogg eller en pakkefangst på tjenesteverten viser kilden som faktisk kom; klientens egen adresse er bare et gjett om hva som overlevde stien.
Betingelse tre: er navnet knyttet til en tjeneste eller til en vert?
Et navn som peker på adressen til én maskin, kobler hver klient til den maskinen. Et navn som peker på en lastbalanserer eller en stabil tjenesteadresse, overlever utskifting av verten bak den. Velg med vilje, for å endre dette senere betyr å endre bokmerkene til hver klient og emnet til hvert sertifikat.
For én enkelt intern tjeneste er en direkte oppføring vanligvis grei og enklere å tenke på.
For alt som skal skiftes ut, bygges på nytt eller skaleres, er en stabil front ende verdt den ekstra konfigurasjonen. Testen er enkel: hvis du kan skifte ut backend uten å fortelle brukerne det, er navnet knyttet til tjenesten; hvis ikke, er det knyttet til en vert.
Test de to beslutningene hver for seg
Slå opp først, og koble til etterpå. En oppslagstest som returnerer den forventede adressen, beviser navnestien og sier ingenting om tilgang. En tilkoblingstest beviser stien og regelen sammen, så kjør den bare etter at oppslaget har lykkes.
curl -sv --max-time 5 https://files.corp.example/health
Test deretter en forbudt kilde én gang, og noter resultatet.
Hold de to oppføringene atskilt i dokumentasjonen din: navnet og sonen, de tillatte kildene og eieren av regelen. Når den ene endres, trenger ikke den andre å endres.
Hvor beslutningen vanligvis går galt
Den vanlige feilen er en tjeneste publisert under et navn som bare slås opp på kontornettet, med en tilgangsregel som bare tillater kontorområdet. Eksterne brukere rapporterer da en ødelagt tjeneste som faktisk er to separate utelatelser. Den andre vanlige feilen er det motsatte: en bred tilgangsregel lagt til for å fjerne et navneproblem, lar tjenesten være tilgjengelig fra kilder ingen hadde til hensikt. Begge er konfigurasjonsutelatelser, og fra brukerens stol ser de like ut.
Ingen av feilene er synlige fra én vellykket test. Derfor fortjener de to beslutningene separate oppføringer og separate tester, selv når samme person tar begge.
Skriv begge ned før tjenesten settes i drift, for den neste endringen blir lettere å tenke på. Oppføringen er kort: én linje for navnet og sonen, én linje for de tillatte kildene og eieren av regelen.