To spørgsmål blandes sammen, når en privat tjeneste åbnes for fjernbrugere. Det første er, hvilket navn klienter skal bruge; det andet er, hvilke kilder tjenesten skal tillade. Besvar dem i den rækkefølge, for et korrekt navn bag en forkert adgangsregel fejler stadig, og en korrekt regel bag et navn, der ikke slår op, bliver aldrig testet.

Betingelse et: hvilken resolversti har klienterne?

Et privat navn virker kun, hvis klientens resolver kan svare på det. Det betyder, at en autoriseret fjernklient skal nå en DNS-server, der holder zonen, enten gennem tunnelen eller gennem en resolver, som organisationen allerede kører for fjernbrugere. Tunnelen er en transport, ikke en fortegnelse. Den giver klienten en sti til en resolver og fortæller ikke, hvilken zone den skal spørge om.

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

En offentlig resolver lærer ikke en privat zone, fordi laptoppen er forbundet til en VPN.

Suffikset fortjener samme opmærksomhed. Brug et underdomæne af et domæne, organisationen kontrollerer, så ejerskab og certifikatplanlægning forbliver tydelige. Undgå .local: specifikationen for multicast DNS binder det suffiks til link-local-opslag, og en rutet tunnel gengiver ikke den adfærd for dig.

Betingelse to: hvilken kilde modtager tjenesten?

Adgangsregler skrives mod adresser, så det nyttige spørgsmål er, hvilken adresse tjenesten ser efter routing og oversættelse. For en eksempeltjeneste på 10.20.30.40 kommer kontorklienter fra 10.20.30.0/24 og fjernklienter fra en separat pulje som 10.99.0.0/24.

Hvis en gateway oversætter fjernpuljen, ser tjenesten oversætteren, og en regel skrevet for 10.99.0.0/24 vil ikke matche.

Læs dette fra tjenestens side i stedet for klientens side. En lytterlog eller en pakkefangst på tjenesteværten viser den kilde, der faktisk ankom; klientens egen adresse er kun et gæt på, hvad der overlevede stien.

Betingelse tre: er navnet knyttet til en tjeneste eller til en vært?

Et navn, der peger på én maskines adresse, kobler hver klient til den maskine. Et navn, der peger på en load balancer eller en stabil tjenesteadresse, overlever udskiftning af værten bag den. Vælg bevidst, for at ændre dette senere betyder at ændre hver klients bogmærker og hvert certifikats emne.

For en enkelt intern tjeneste er en direkte post normalt fin og lettere at tænke over.

For alt, der vil blive udskiftet, genopbygget eller skaleret, er en stabil front end den ekstra konfiguration værd. Testen er enkel: hvis du kan udskifte backenden uden at fortælle brugerne det, er navnet knyttet til tjenesten; hvis du ikke kan, er det knyttet til en vært.

Test de to beslutninger hver for sig

Slå først op, og forbind derefter. En opslagstest, der returnerer den forventede adresse, beviser navnestien og siger intet om adgang. En forbindelsestest beviser stien og reglen sammen, så kør den først, efter opslaget er lykkedes.

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

Test derefter en forbudt kilde én gang, og noter resultatet.

Hold de to poster adskilt i din dokumentation: navnet og dets zone, de tilladte kilder og reglens ejer. Når den ene ændres, behøver den anden ikke.

Hvor beslutningen normalt går galt

Den almindelige fejl er en tjeneste, der offentliggøres under et navn, som kun slår op på kontornettet, med en adgangsregel, der kun tillader kontorintervallet. Fjernbrugere rapporterer så en brudt tjeneste, som i virkeligheden er to separate undladelser. Den anden almindelige fejl er det omvendte: en bred adgangsregel tilføjet for at fjerne et navneproblem efterlader tjenesten tilgængelig fra kilder, som ingen havde tænkt på. Begge er konfigurationsundladelser, og fra brugerens stol ser de ens ud.

Ingen af fejlene er synlige fra en enkelt vellykket test. Derfor fortjener de to beslutninger separate poster og separate tests, selv når den samme person træffer dem begge.

Skriv begge ned, før tjenesten går i drift, for den næste ændring bliver lettere at tænke over. Posten er kort: én linje til navnet og dets zone, én linje til de tilladte kilder og reglens ejer.

Relaterede artikler