Privat DNS-namn eller berre ein IP? Avgjer før du deler det

To spørsmål blir blanda saman når ei privat teneste blir opna for eksterne brukarar. Det første er kva namn klientane skal bruke; det andre er kva kjelder tenesta skal tillate. Svar på dei i den rekkjefølgja, for eit korrekt namn bak ein feil tilgangsregel feilar framleis, og ein korrekt regel bak eit namn som ikkje blir slått opp, blir aldri testa.

Vilkår éin: kva resolversti har klientane?

Eit privat namn verkar berre dersom resolveren til klienten kan svare på det. Det tyder at ein autorisert ekstern klient må nå ein DNS-server som held sona, anten gjennom tunnelen eller gjennom ein resolver organisasjonen allereie køyrer for eksterne brukarar. Tunnelen er ein transport, ikkje ein katalog. Han gjev klienten ein sti til ein resolver, og han fortel ikkje klienten kva sone han skal spørje om.

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

Ein offentleg resolver lærer ikkje ei privat sone fordi laptopen er kopla til ein VPN.

Suffikset fortener same merksemd. Bruk eit underdomene av eit domene organisasjonen kontrollerer, slik at eigarskap og sertifikatplanlegging blir verande tydelege. Unngå .local: spesifikasjonen for multicast DNS bind det suffikset til link-local-oppslag, og ein ruta tunnel attskapar ikkje den åtferda for deg.

Vilkår to: kva kjelde mottek tenesta?

Tilgangsreglar blir skrivne mot adresser, så det nyttige spørsmålet er kva adresse tenesta ser etter ruting og omsetjing. For ei dømeteneste på 10.20.30.40 kjem kontorklientar frå 10.20.30.0/24 og eksterne klientar frå ein eigen pool som 10.99.0.0/24.

Viss ein gateway omset den eksterne poolen, ser tenesta omsetjaren, og ein regel skriven for 10.99.0.0/24 vil ikkje stemme.

Les dette frå sida til tenesta i staden for sida til klienten. Ein lyttarlogg eller ein pakkefangst på tenesteverten viser kjelda som faktisk kom; den eigne adressa til klienten er berre eit gjet om kva som overlevde stien.

Vilkår tre: er namnet knytt til ei teneste eller til ein vert?

Eit namn som peikar på adressa til éin maskin, koplar kvar klient til den maskinen. Eit namn som peikar på ein lastbalansar eller ei stabil tenesteadresse, overlever utskifting av verten bak han. Vel med vilje, for å endre dette seinare tyder å endre bokmerka til kvar klient og emnet til kvart sertifikat.

For éi einskapleg intern teneste er ein direkte oppføring vanlegvis grei og enklare å tenkje på.

For alt som skal skiftast ut, byggjast på nytt eller skalerast, er ein stabil front ende verd den ekstra konfigurasjonen. Testen er enkel: viss du kan skifte ut backend utan å fortelje brukarane det, er namnet knytt til tenesta; viss ikkje, er det knytt til ein vert.

Test dei to avgjerdene kvar for seg

Slå opp først, og kople til etterpå. Ein oppslagstest som returnerer den forventa adressa, provar namnestien og seier ingenting om tilgang. Ein tilkoplingstest provar stien og regelen saman, så køyr han berre etter at oppslaget har lukkast.

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

Test deretter ei forbode kjelde éin gong, og noter resultatet.

Hald dei to oppføringane åtskilde i dokumentasjonen din: namnet og sona, dei tillatne kjeldene og eigaren av regelen. Når den eine blir endra, treng ikkje den andre å bli endra.

Kvar avgjerda vanlegvis går gale

Den vanlege feilen er ei teneste publisert under eit namn som berre blir slått opp på kontornettet, med ein tilgangsregel som berre tillèt kontorområdet. Eksterne brukarar rapporterer då ei øydelagd teneste som faktisk er to separate utelatingar. Den andre vanlege feilen er det motsette: ein brei tilgangsregel lagt til for å fjerne eit namnepproblem, lèt tenesta vere tilgjengeleg frå kjelder ingen hadde til hensikt. Begge er konfigurasjonsutelatingar, og frå stolen til brukaren ser dei like ut.

Ingen av feila er synlege frå éin vellukka test. Derfor fortener dei to avgjerdene separate oppføringar og separate testar, sjølv når same person tek begge.

Skriv begge ned før tenesta blir sett i drift, for den neste endringa blir lettare å tenkje på. Oppføringa er kort: éi linje for namnet og sona, éi linje for dei tillatne kjeldene og eigaren av regelen.