Adresų planai, kurie sako „šis nešiojamasis kompiuteris gauna 10.90.0.10“, iš tikrųjų yra teiginiai apie tapatybę: kuris autentifikuotas įrenginys gali turėti šį adresą. Dabartinis to įrenginio viešasis IP tam beveik neturi reikšmės, nes NAT ir roamingas jį keičia nekeisdami to, kas yra naudotojas. Planą statant ant šaltinio adreso gaunamos taisyklės, kurios lūžta pirmame viešbučio tinkle. Statant jį ant autentifikuotos tapatybės gaunamas planas, kuris atlaiko keliones.

Pradėkite nuo to, ką serveris gali patikrinti, tada nuspręskite, kam skirtas adresas.

Pasirinkite tapatybės raktą prieš adresą

Atskiras kliento sertifikatas kiekvienam įrenginiui suteikia serveriui stabilų, patikrinamą raktą kiekvienam nariui, o tai yra švariausias statinio priskyrimo pagrindas. Diegimas, naudojantis autentifikaciją pagal naudotoją, gali vietoj to remtis naudotojo vardu, jei konfigūracijos pasirinkimas vadovaujasi tuo pačiu lauku. Sumaišius abu modelius gaunami priskyrimai, kurie vienam klientui atitinka sertifikatą, o kitam – naudotojo vardą, ir niekas negali numatyti, kuris laimės. Nuspręskite, kurį raktą naudoja planas, prieš rašydami bent vieną rezervaciją.

Naudojant duplicate-cn keli vienu metu vykstantys seansai gali pateikti tą patį bendrą vardą, todėl vienas prisegtas adresas negali jų atpažinti atskirai. Tai tapatybės modelio savybė, o ne tai, ką galėtų ištaisyti geresnis adresų planas.

Rezervuokite adresus už dinaminio diapazono ribų

Tinkle su potinklio topologija, pavyzdžiui, 10.90.0.0/24, palikite žemus adresus įvardytiems nariams, o dinaminį baseiną dėkite į atskirą diapazoną. Prisegto nario priskyrimas atrodo taip ifconfig-push 10.90.0.10 255.255.255.0 faile, kurį serveris parenka tai tapatybei. Antrasis argumentas pagal net30 reiškia ką kita, todėl pavyzdys nėra neutralus topologijos atžvilgiu. Perskaitykite topologiją prieš jį kopijuodami.

Baseino išliekamumas įrašo naujausias nuomas ir linkęs grąžinti tą patį adresą, o tai patogumas, o ne rezervacija. Neleiskite išliekamumo failui tapti nuosavybės įrašu, nes jis kinta su prisijungimų istorija, o ne su politika.

Priskyrimo eiliškumas nusprendžia, kas laimi

Vadove dokumentuojama tvarka: aiškus priskyrimas, sukurtas per client-connect, gali įsigalioti prieš client-config-dir įrašą, kuris savo ruožtu eina prieš įprastą baseino paskirstymą. Ši tvarka paaiškina daugumą pranešimų „prisegtas adresas nebuvo pritaikytas“. Tai taip pat reiškia, kad dinaminis skirstytuvas, rašantis kiekvieno seanso konfigūraciją, gali tyliai perrašyti statinį failą, kurį laikėte autoritetingu.

Pasirinkite vieną sluoksnį, kuris valdo priskyrimus, o kitus padarykite tik skaitomus. Du sluoksniai, kurie abu teigia sprendžiantys, sukuria nuo laiko priklausančius priskyrimus.

Dinaminiam skirstytuvui reikia to paties modelio

Client-connect integracija, kuri dalija adresus kiekvienam seansui, yra mažas skirstytuvas su įprastomis skirstytuvo problemomis. Ji turi patikrinti prašančią tapatybę, atominėmis operacijomis rezervuoti adresą, išvesti tik palaikomą kiekvieno ryšio išvestį ir atlaisvinti rezervaciją atsijungus arba nepavykus. Vienu metu einančioms užklausoms reikia užrakto arba duomenų bazės apribojimo, o ne skaitymo-ir-tada-rašymo sekos. Be valymo baseinas nuteka adresus iki paleidimo iš naujo.

Laikykite skirstytuvo būseną ten, kur kitas operatorius galės ją perskaityti, ir registruokite sprendimą tapatybė-į-adresą, o ne vien adresą.

Nuspręskite, ar adresas yra politika, ar patogumas

Jei užkardos taisyklė arba maršrutas leidžia srautą iš vieno tunelio adreso, tada adresas dalyvauja prieigos politikoje ir perpriskyrimas paveldi tą leidimą. Derinkite tapatybės, adreso ir užkardos gyvavimo ciklą arba susiekite taisyklę su tuo, ko negalima perpriskirti. Stabilus adresavimas daro konfigūraciją įskaitomą; jis nepakeičia autentifikavimo.

Rašykite planą kaip inventorių su savininku prie kiekvieno įrašo, tada peržiūrėkite jį, kai įrenginys išimamas iš eksploatacijos. Nenaudojama rezervacija yra ta, kuri netyčia panaudojama pakartotinai.

Susiję straipsniai