Julkinen, yksityinen, staattinen ja oma ovat toisistaan riippumattomia osoiteominaisuuksia. Rakenna käyttöönoton kartta, joka kattaa myös reitityksen, palomuurit, edellyttävän DNS-määrityksen, käänteisen DNS-määrityksen ja TLS-määrityksen, ja varmista jokainen asetus sen osapuolen kanssa, joka hallitsee sitä.
Osoitteen ominaisuudet vastaavat eri kysymyksiin
Julkinen ja yksityinen kuvaavat, minne osoite on tarkoitettu reititettäväksi. Staattinen ja dynaaminen kuvaavat, miten määritys käyttäytyy ajan myötä. Oma ja jaettu kuvaavat, miten osoitetta käytetään tai allokoidaan palvelussa. Nämä ovat erillisiä ominaisuuksia: vakaa julkinen osoite voi palvella monia sivustoja, ja yksityinen osoite voidaan määrittää dynaamisesti hallitussa verkossa.
Kirjoita kunkin osoitteen rooli käyttöönotossa: julkinen tulopiste, sisäinen tietokanta, hallintareitti tai lähtevä yhteys. Tunnista sitten, kuka sen määrittää ja mikä voi muuttua. Tämä estää kokoonpanotyön riippumasta oletuksesta, kuten että oma tarkoittaa pysyvästi kiinteää tai julkinen tarkoittaa, että palvelu on tavoitettavissa. Tavoitettavuus riippuu myös reitityksestä, palomuureista ja sovelluksen kuuntelijasta.
Yksityinen osoitteistus tarvitsee silti reititystä ja käyttöoikeuksien hallintaa
RFC 1918 varaa IPv4-alueet 10.0.0.0/8, 172.16.0.0/12 ja 192.168.0.0/16 yksityisille verkoille. Niiden osoitteet eivät ole maailmanlaajuisesti yksilöllisiä julkisia kohteita. Verkko voi kääntää yksityisiä osoitteita lähteviä yhteyksiä varten tai yhdistää yksityisiä verkkoja nimenomaisten reittien kautta. Käännöksen takana oleva saapuva palvelu tarvitsee tarkoituksellisen julkaisumenetelmän; pelkän DNS-tietueen muuttaminen ei luo tätä reittiä.
IPv6:lla on omat osoitetyyppinsä ja laajuutensa, mukaan lukien linkkipaikallinen osoitteistus ja maailmanlaajuisesti reititettävät unicast-osoitteet. Tarkastele sitä erikseen sen sijaan, että olettaisit IPv4-palomuurin tai käännössäännön kattavan IPv6-määrityksen. Yksityinen osoite ei ole todennusmekanismi, eikä julkinen IPv6-osoite ole syy paljastaa kaikkia palveluita. Testaa pääsy jokaisesta asiaankuuluvasta verkosta ja rajoita hallintaa asianmukaisella rajalla.
Vakaat nimet ja vakaat osoitteet liittyvät toisiinsa
DHCP allokoi osoitekokoonpanon protokollan kautta ja voi käyttää vuokra-aikoja. Dynaamisesti määritetty osoite voi pysyä muuttumattomana jonkin aikaa; se ei tee sen pysyvyydestä sopimuksellista takuuta. Kun sovellus riippuu vakaasta osoitteesta, varmista palveluntarjoajan määritys- ja muutospolitiikka sen sijaan, että päättelet sen eilisestä yhteydestä.
Dynaaminen DNS voi päivittää nimen osoitteen muuttumisen jälkeen, mutta asiakkaat voivat silti välimuistiin tallentaa edellisen vastauksen. Se ei myöskään voi voittaa tavoittamattomissa olevaa kuuntelijaa, puuttuvaa saapuvaa reittiä tai operaattoritason osoitteenkäännöstä. Käytä sitä, kun verkko sallii yhteyden ja sovellus sietää päivitysviiveitä. Dokumentoi isännöidyssä käyttöönotossa aiottu osoitteen elinkaari ennen kuin rakennat sallittujen luetteloita tai ulkoisia integraatioita sen ympärille.
| Ominaisuus | Mitä vahvistaa | Yleinen virheellinen oletus |
|---|---|---|
| Julkinen vai yksityinen | Reitityksen laajuus ja käyttöpolku | Pelkkä osoite tekee palvelusta tavoitettavan |
| Staattinen vai dynaaminen | Määritys- ja muutospolitiikka | Muuttumaton vuokra on pysyvä |
| Oma vai jaettu | Allokaatio ja sallittu käyttö | Oma osoite tarjoaa anonyymin identiteetin |
| IPv4 vai IPv6 | Sekä reititys- että palomuurikokoonpanot | Yhden protokollan asetukset kattavat toisen |
Edellyttävällä DNS- ja käänteisellä DNS-määrityksellä on eri omistajat
Edellyttävä DNS yhdistää nimet tietoihin, kuten A- ja AAAA-osoitetietueisiin. Käänteinen DNS käyttää osoitteeseen liittyvää nimiavaruutta ja PTR-tietueita liittääkseen osoitteen nimeen. Organisaatio, joka hallitsee edellyttävää DNS-vyöhykettä, ei välttämättä ole organisaatio, joka hallitsee osoitealueen käänteistä DNS-määritystä. Hanki oikea kokoonpanopolku ennen kuin lupaat käänteisen nimen.
Tarkista tietue asianmukaisen resolverin kautta ja kirjaa tulos. Jos PTR on tarkoitettu isäntäkoneen tunnistamiseen, tarkista myös, osoittaako vastaava edellyttävä tietue odotettuun osoitteeseen. Käänteinen DNS voi tukea toiminnallista tunnistamista ja joitakin sähköpostijärjestelmän tarkistuksia, mutta se ei todista sovellusta eikä takaa viestin toimitusta. Sähköpostin lähettäminen tarvitsee myös oman verkkotunnuksen, maineen ja todennuksen tarkistuksen.
Omaa osoitetta ei tarvita jokaiseen HTTPS-sivustoon
HTTP-isäntäreititys ja TLS Server Name Indication -laajennus antavat tuettujen asiakkaiden ja palvelimien valita sivuston tai varmenteen nimen perusteella. Useat HTTPS-sivustot voivat siksi käyttää yhtä osoitetta ilman, että jokainen verkkotunnus tarvitsee oman julkisen osoitteen. Todellinen isännöintikokoonpano ja vaaditut asiakkaat ratkaisevat, sopiiko tämä järjestely.
Valitse ylimääräinen osoite vain, kun dokumentoitu vaatimus edellyttää sitä, kuten tuettu verkon eriyttäminen tai ulkoinen järjestelmä, joka odottaa erillistä päätepistettä. Osoite ei anna suojaa maineongelmilta eikä tunnista palvelua käyttävää henkilöä. Pidä varmenteet, isäntänimireititys ja osoitteen allokaatio erillisinä tarkistuksina. Varmista tarjottu varmenne sen isäntänimen kautta, jolla käyttäjät todella vierailevat.
Käytä käyttöönoton karttaa ennen tietueiden muuttamista
Luo pieni kartta, joka sisältää jokaisen isäntänimen, osoitetietueen, kuuntelijan, palomuuripolun ja vastuullisen osapuolen. Sisällytä hallinta, varmuuskopiot ja mahdolliset lähtevät sallitut luettelot. Tarkista, listaako SwissOctet-kokoonpano tarvitsemasi osoitevaihtoehdon, ja kysy käänteisen DNS-määrityksen hallinnasta ennen kuin luotat siihen. Älä esitä luettelon vaihtoehtoja käytössä olevana määrityksenä, joka on jo otettu käyttöön.
Valmistele siirron aikana kohdesovellus ja TLS-asetukset ennen kuin ohjaat käyttäjät sinne. Ota huomioon DNS-välimuistit ja ylläpidä toimivaa palautuspolkua. Varmista edellyttävä nimiresoluutio, todellinen sovelluksen tavoitettavuus ja odotettu käänteinen nimi erikseen. Kartta helpottaa vikojen paikantamista, koska väärä tietue, suljettu portti ja yhteensopimaton varmenne ovat eri ongelmia, joilla on eri omistajat.
Käytännön tarkistuslistasi.
- Kartoita osoitteen rooli, määritys ja omistajuus.
- Tarkista IPv4 ja IPv6 erikseen.
- Varmista saapuva reititys ennen kuin luotat DNS-määritykseen.
- Tunnista, kuka hallitsee PTR-tietueita.
- Testaa isäntänimi, varmenne ja sovellus yhdessä.
Olennaiset yksityiskohdat.
Tekevätkö omat IP-osoitteet palvelusta anonyymin?+
Ei. Se kuvaa allokaatio- tai käyttöjärjestelyä, ei identiteetti- tai yksityisyystakuuta. Tilit, liikenne ja sovellustiedot vaikuttavat erikseen.
Voinko määrittää PTR-tietueet verkkotunnukseni DNS-paneelista?+
Vain jos se hallitsee myös asiaankuuluvaa käänteistä vyöhykettä. Osoitepalveluntarjoaja hallitsee yleensä tätä vyöhykettä tai tarjoaa erillisen pyyntöprosessin.
Tarvitseeko jokainen HTTPS-verkkotunnus oman osoitteen?+
Ei välttämättä. Tuetut asiakkaat ja palvelimet voivat käyttää nimipohjaista reititystä ja TLS SNI -laajennusta. Varmista todellinen isännöinti ja asiakasvaatimukset.
Mene lähteelle.
Nämä lähteet tukevat tämän oppaan teknisiä käsitteitä. Noudata ajantasaisia dokumentaatioita ennen tuotantojärjestelmän muuttamista.
- RFC 1918: Osoitteiden allokointi yksityisille verkoille www.rfc-editor.org
- RFC 2131: Dynamic Host Configuration Protocol www.rfc-editor.org
- RFC 1035: DNS-toteutus ja määrittely www.rfc-editor.org
- RFC 4291: IPv6-osoitteistusarkkitehtuuri www.rfc-editor.org
- RFC 6066: TLS-laajennukset, mukaan lukien Server Name Indication www.rfc-editor.org
Toimituksellinen ohjaus: SwissOctet. Esimerkit ovat havainnollistavia. Palvelumääritykset, saatavilla olevat vaihtoehdot ja sopimusehdot on tarkistettava erikseen.