Privaatne DNS-nimi või lihtsalt IP? Otsustage enne, kui jagate

Kaks küsimust segunevad, kui privaatne teenus avatakse kaugkasutajatele. Esimene on, millist nime kliendid peaksid kasutama; teine on, milliseid allikaid teenus peaks lubama. Vastake neile selles järjekorras, sest õige nimi vale juurdepääsureegli taga ebaõnnestub ikka, ja õige reegel nime taga, mis ei lahene, jääb kunagi testimata.

Tingimus üks: milline resolveri tee klientidel on?

Privaatne nimi töötab ainult siis, kui kliendi resolver suudab sellele vastata. See tähendab, et volitatud kaugklient peab jõudma DNS-serverini, mis hoiab tsooni, kas tunneliga või resolveriga, mida organisatsioon juba kaugkasutajate jaoks käitab. Tunnel on transport, mitte kataloog. See annab kliendile tee resolverini ega ütle, millist tsooni küsida.

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

Avalik resolver ei õpi privaatset tsooni sellepärast, et sülearvuti ühendati VPN-iga.

Järelliide väärib sama tähelepanu. Kasutage organisatsiooni kontrollitava domeeni alamdomeeni, et omand ja sertifikaatide planeerimine jääksid selgeks. Vältige .local: multicast DNS-i spetsifikatsioon seob selle järelliite link-local lahendusega ja marsruuditud tunnel ei korda seda käitumist teie eest.

Tingimus kaks: millise allika teenus saab?

Juurdepääsureeglid kirjutatakse aadresside vastu, seega kasulik küsimus on, millist aadressi teenus näeb pärast marsruutimist ja tõlget. Näidisteenuse jaoks aadressil 10.20.30.40 tulevad kontorikliendid aadressilt 10.20.30.0/24 ja kaugkliendid eraldi vahemikust, näiteks 10.99.0.0/24.

Kui lüüs tõlgib kaugvahemikku, näeb teenus tõlkijat, ja aadressile 10.99.0.0/24 kirjutatud reegel ei sobi.

Lugege seda teenuse poolelt, mitte kliendi poolelt. Kuulaja logi või paketipüük teenuse hostis näitab allikat, mis tegelikult saabus; kliendi enda aadress on vaid oletus selle kohta, mis teekonnal vastu pidas.

Tingimus kolm: kas nimi on seotud teenusega või hostiga?

Nimi, mis osutab ühe masina aadressile, seob iga kliendi selle masinaga. Nimi, mis osutab koormustasakaalustajale või stabiilsele teenuse aadressile, elab üle selle taga oleva hosti väljavahetamise. Valige teadlikult, sest hilisem muutmine tähendab iga kliendi järjehoidjate ja iga sertifikaadi subjekti muutmist.

Ühe sisemise teenuse jaoks on otsene kirje tavaliselt hea ja lihtsam mõelda.

Kõige jaoks, mis asendatakse, taastatakse või skaleeritakse, on stabiilne esiots lisakonfiguratsiooni väärt. Test on lihtne: kui saate tagakülge vahetada kasutajatele ütlemata, on nimi seotud teenusega; kui ei saa, on see seotud hostiga.

Testige kahte otsust eraldi

Kõigepealt lahendage, seejärel ühenduge. Lahendustest, mis tagastab oodatud aadressi, tõestab nime tee ja ei ütle midagi juurdepääsu kohta. Ühendustest tõestab tee ja reegli koos, seega käivitage see alles pärast lahenduse õnnestumist.

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

Seejärel testige üks kord keelatud allikat ja kirjutage tulemus üles.

Hoidke kaks kirjet dokumentatsioonis eraldi: nimi ja selle tsoon, lubatud allikad ja reegli omanik. Kui üks muutub, ei pea teine muutuma.

Kus otsus tavaliselt valesti läheb

Tavaline viga on teenus, mis on avaldatud nime all, mis laheneb ainult kontorivõrgus, koos juurdepääsureegliga, mis lubab ainult kontori vahemikku. Kaugkasutajad teatavad siis katkisest teenusest, mis on tegelikult kaks eraldi puudujääki. Teine tavaline viga on vastupidine: nimeprobleemi kõrvaldamiseks lisatud lai juurdepääsureegel jätab teenuse kättesaadavaks allikatest, mida keegi ei kavatsenud. Mõlemad on konfiguratsiooni puudujäägid ja kasutaja toolilt näevad need ühesugused välja.

Kumbki viga ei ole ühest õnnestunud testist nähtav. Seepärast väärivad kaks otsust eraldi kirjeid ja eraldi teste, isegi kui sama inimene teeb mõlemad.

Kirjutage mõlemad üles enne, kui teenus tööle läheb, sest järgmist muudatust on lihtsam läbi mõelda. Kirje on lühike: üks rida nime ja selle tsooni jaoks, üks rida lubatud allikate ja reegli omaniku jaoks.