Privát DNS-név vagy csak egy IP? Döntsön, mielőtt megosztja
A nevet a feloldó útvonala alapján, a hozzáférési szabályt pedig a szolgáltatás által látott forrás alapján válassza. Ez két külön döntés, és mindegyiknek megvan a maga próbája.
Két kérdés keveredik össze, amikor egy privát szolgáltatást távoli felhasználók előtt nyitnak meg. Az első az, milyen nevet használjanak az ügyfelek; a második az, mely forrásokat engedje be a szolgáltatás. Ebben a sorrendben válaszoljon rájuk, mert a rossz hozzáférési szabály mögötti helyes név is elbukik, és a nem feloldódó név mögötti helyes szabály soha nem kerül próbára.
Első feltétel: milyen feloldó útvonala van az ügyfeleknek?
Egy privát név csak akkor működik, ha az ügyfél feloldója meg tud rá válaszolni. Ez azt jelenti, hogy egy feljogosított távoli ügyfélnek el kell érnie a zónát tartó DNS-kiszolgálót, akár az alagúton, akár egy olyan feloldón keresztül, amelyet a szervezet már futtat a távoli felhasználóknak. Az alagút szállítás, nem névjegyzék. Útvonalat ad az ügyfélnek egy feloldóhoz, és nem mondja meg neki, melyik zónát kérdezze.
resolvectl query files.corp.example
dig @10.20.30.10 +short files.corp.example
Egy nyilvános feloldó nem tanul meg egy privát zónát attól, hogy a laptop VPN-hez csatlakozott.
Az utótag ugyanannyi figyelmet érdemel. Használjon a szervezet által ellenőrzött tartomány alá tartozó aldomaint, hogy a tulajdonjog és a tanúsítvány tervezése egyértelmű maradjon. Kerülje a .local-t: a multicast DNS specifikáció ehhez az utótaghoz köti a link-local feloldást, és egy átirányított alagút nem reprodukálja ezt a viselkedést Önnek.
Második feltétel: mely forrást kapja a szolgáltatás?
A belépési szabályok címekhez íródnak, ezért a hasznos kérdés az, melyik címet látja a szolgáltatás az útválasztás és a fordítás után. Egy példaszolgáltatás esetén a 10.20.30.40 címen az irodai ügyfelek a 10.20.30.0/24 címről érkeznek, a távoli ügyfelek pedig külön készletből, például 10.99.0.0/24 címről.
Ha egy átjáró lefordítja a távoli készletet, a szolgáltatás a fordítót látja, és a 10.99.0.0/24 címre írt szabály nem fog illeszkedni.
Ezt a szolgáltatás oldaláról olvassa, ne az ügyfél oldaláról. A szolgáltatás gazdagépén lévő figyelőnapló vagy csomagrögzítés mutatja a ténylegesen érkezett forrást; az ügyfél saját címe csak találgatás arról, mi élte túl az útvonalat.
Harmadik feltétel: a név szolgáltatáshoz vagy gazdagéphez kötődik?
Egy gép címére mutató név minden ügyfelet ehhez a géphez köt. Egy terheléselosztóra vagy stabil szolgáltatáscímre mutató név túléli a mögötte lévő gazdagép cseréjét. Válasszon tudatosan, mert ezt később megváltoztatni annyit jelent, hogy minden ügyfél könyvjelzőjét és minden tanúsítvány tárgyát meg kell változtatni.
Egyetlen belső szolgáltatás esetén a közvetlen rekord általában rendben van, és könnyebb átgondolni.
Mindenhez, amit lecserélnek, újraépítenek vagy méreteznek, egy stabil előtér megéri a plusz konfigurációt. A próba egyszerű: ha a háttérrendszert a felhasználók értesítése nélkül le tudja cserélni, a név a szolgáltatáshoz kötődik; ha nem, akkor egy gazdagéphez.
Tesztelje a két döntést külön
Először oldja fel, aztán csatlakozzon. Az elvárt címet visszaadó feloldási próba bizonyítja a név útvonalát, és semmit nem mond a belépésről. A csatlakozási próba az útvonalat és a szabályt együtt bizonyítja, ezért csak sikeres feloldás után futtassa.
curl -sv --max-time 5 https://files.corp.example/health
Ezután egyszer próbáljon ki egy tiltott forrást, és rögzítse az eredményt.
Tartsa a két rekordot külön a dokumentációjában: a nevet és a zónáját, az engedélyezett forrásokat és a szabály tulajdonosát. Amikor az egyik változik, a másiknak nem kell.
Hol szokott félremenni a döntés
A gyakori hiba egy olyan név alatt közzétett szolgáltatás, amely csak az irodai hálózaton oldódik fel, olyan belépési szabállyal, amely csak az irodai tartományt engedi be. A távoli felhasználók ekkor egy elromlott szolgáltatást jelentenek, amely valójában két külön kihagyás. A második gyakori hiba az ellenkezője: egy széles belépési szabály, amelyet egy névprobléma eltüntetésére adtak hozzá, olyan forrásokból teszi elérhetővé a szolgáltatást, amelyeket senki nem szándékozott. Mindkettő konfigurációs kihagyás, és a felhasználó székéből ugyanúgy néznek ki.
Egyik hiba sem látszik egyetlen sikeres próbából. Ezért érdemel a két döntés külön rekordot és külön próbákat, akkor is, ha ugyanaz a személy hozza mindkettőt.
Írja le mindkettőt, mielőtt a szolgáltatás élesbe kerül, mert a következő változást könnyebb lesz átgondolni. A rekord rövid: egy sor a névnek és a zónájának, egy sor az engedélyezett forrásoknak és a szabály tulajdonosának.