Osoitesuunnitelmat, jotka sanovat ”tämä kannettava saa 10.90.0.10”, ovat itse asiassa väitteitä identiteetistä: mikä todennettu laite saa pitää kyseistä osoitetta. Kyseisen laitteen nykyisellä julkisella IP:llä ei ole juuri mitään tekemistä asian kanssa, koska NAT ja roaming muuttavat sitä muuttamatta sitä, kuka käyttäjä on. Suunnitelman rakentaminen lähdeosoitteen varaan tuottaa sääntöjä, jotka hajoavat ensimmäisessä hotelliverkossa. Sen rakentaminen todennetun identiteetin varaan tuottaa suunnitelman, joka kestää matkustamisen.

Aloita siitä, mitä palvelin voi tarkistaa, ja päätä sitten, mihin osoite on tarkoitettu.

Valitse identiteettiavain ennen osoitetta

Erillinen asiakasvarmenne joka laitteelle antaa palvelimelle vakaan, todennettavan avaimen jokaiselle jäsenelle, mikä on puhtain perusta staattiselle määritykselle. Käyttäjäkohtaista todennusta käyttävä käyttöönotto voi sen sijaan nojata käyttäjänimeen, kunhan kokoonpanon valinta seuraa samaa kenttää. Kahden mallin sekoittaminen tuottaa määrityksiä, jotka sopivat yhdelle asiakkaalle varmenneeseen ja toiselle käyttäjänimeen, eikä kukaan voi ennustaa, kumpi voittaa. Päätä, mitä avainta suunnitelma käyttää, ennen kuin kirjoitat yhtäkään varausta.

duplicate-cn-asetuksella useat samanaikaiset istunnot voivat esittää samaa yleisnimeä, joten yksi kiinnitetty osoite ei voi tunnistaa niitä yksittäin. Tämä on identiteettimallin ominaisuus, ei jotain, minkä parempi osoitesuunnitelma voisi korjata.

Varaa osoitteet dynaamisen alueen ulkopuolelta

Aliverkkotopologiaa käyttävässä verkossa, kuten 10.90.0.0/24, pidä matalat osoitteet nimetyille jäsenille ja sijoita dynaaminen allas erilliselle alueelle. Kiinnitetyn jäsenen määritys näyttää tältä ifconfig-push 10.90.0.10 255.255.255.0 tiedostossa, jonka palvelin valitsee kyseiselle identiteetille. Toinen argumentti tarkoittaa net30:ssä jotain muuta, joten esimerkki ei ole topologiariippumaton. Lue topologia ennen kuin kopioit sen.

Altaan pysyvyys kirjaa viimeaikaiset vuokrat ja tapaa palauttaa saman osoitteen, mikä on mukavuus, ei varaus. Älä anna pysyvyystiedoston tulla omistuksen kirjaksi, koska se muuttuu yhteyshistorian eikä käytännön mukaan.

Määrityksen etusija ratkaisee, kuka voittaa

Käsikirja dokumentoi järjestyksen: client-connectin aikana luotu nimenomainen määritys voi tulla voimaan ennen client-config-dir-merkintää, joka puolestaan edeltää tavallista altaan jakoa. Tämä järjestys selittää useimmat raportit ”kiinnitetty osoite ei tullut voimaan”. Se tarkoittaa myös, että dynaaminen jakaja, joka kirjoittaa istuntokohtaisen kokoonpanon, voi ääneti ohittaa staattisen tiedoston, jota pidit auktoritatiivisena.

Valitse yksi kerros, joka omistaa määritykset, ja tee muista vain luku -kelpoisia. Kaksi kerrosta, jotka molemmat väittävät päättävänsä, tuottavat ajoituksesta riippuvia määrityksiä.

Dynaaminen jakaja tarvitsee saman mallin

Client-connect-integraatio, joka jakaa osoitteita istunnoittain, on pieni jakaja, jolla on tavalliset jakajan ongelmat. Sen on validoitava pyytävä identiteetti, varattava osoite atomisesti, tulostettava vain tuettu yhteyskohtainen tulos ja vapautettava varaus yhteyden katketessa tai epäonnistuessa. Samanaikaiset pyynnöt tarvitsevat lukon tai tietokantarajoitteen, eivät lue-sitten-kirjoita-jaksoa. Ilman siivousta allas vuotaa osoitteita uudelleenkäynnistykseen asti.

Pidä jakajan tila siellä, missä seuraava ylläpitäjä voi lukea sen, ja kirjaa identiteetti-osoite-päätös eikä vain osoitetta.

Päätä, onko osoite käytäntöä vai mukavuutta

Jos palomuurisääntö tai reitti sallii liikenteen yhdestä tunneliosoitteesta, osoite osallistuu käyttöoikeuskäytäntöön ja uudelleenmääritys perii kyseisen luvan. Koordinoi identiteetin, osoitteen ja palomuurin elinkaari tai sido sääntö johonkin, jota ei voi määrittää uudelleen. Vakaa osoitteistus tekee kokoonpanosta luettavan; se ei korvaa todennusta.

Kirjoita suunnitelma luetteloksi, jossa jokaisella merkinnällä on omistaja, ja tarkista se, kun laite poistetaan käytöstä. Käyttämätön varaus on se, joka käytetään vahingossa uudelleen.

Aiheeseen liittyvät artikkelit