Vistfangaáætlanir sem segja „þessi fartölva fær 10.90.0.10“ eru í raun fullyrðingar um auðkenni: hvaða sannreynda tæki megi halda því vistfangi. Núverandi opinbert IP þess tækis hefur nánast ekkert með þetta að gera, því NAT og reiki breyta því án þess að breyta því hver notandinn er. Að byggja áætlunina á upprunavistfanginu framleiðir reglur sem brotna á fyrsta hótelnetinu. Að byggja hana á sannreynda auðkenninu framleiðir áætlun sem þolir ferðalög.

Byrjaðu á því sem þjónninn getur sannreynt og ákveddu síðan hvað vistfangið er fyrir.

Veldu auðkennislykilinn fyrir vistfangið

Sérstakt biðlarafervandi fyrir hvert tæki gefur þjóninum stöðugan, sannanlegt lykil fyrir hvern meðlim, sem er hreinasti grundvöllur fastrar úthlutunar. Uppsetning sem notar auðkenningu á hvern notanda getur í staðinn stuðst við notandanafnið, svo framarlega sem val stillingarinnar fylgir sama sviði. Að blanda báðum líkönum framleiðir úthlutanir sem passa við skírteini fyrir einn biðlara og notandanafn fyrir annan, og enginn getur spáð fyrir um hvor vinnur. Ákveddu hvaða lykil áætlunin notar áður en þú skrifar eina einustu frátekningu.

Með duplicate-cn geta nokkrar samtímis setur kynnt sama algenga nafnið, svo eitt fest vistfang getur ekki auðkennt þær hverja fyrir sig. Þetta er eiginleiki auðkennislíkansins, ekki eitthvað sem betri vistfangaáætlun getur lagað.

Fráteknið vistföng utan hreyfanlega bilsins

Í neti með undirnetsktopólógíu eins og 10.90.0.0/24 skaltu halda lágum vistföngum fyrir nefnda meðlimi og setja hreyfanlega laugina í aðskilið bil. Úthlutun fyrir fastan meðlim lítur svona út ifconfig-push 10.90.0.10 255.255.255.0 í skránni sem þjónninn velur fyrir það auðkenni. Seinna viðfangið þýðir eitthvað annað undir net30, svo dæmið er ekki hlutlaust gagnvart topólógíunni. Lestu topólógíuna áður en þú afritar það.

Varanleiki laugarinnar skráir nýlegar leigur og hefur tilhneigingu til að skila sama vistfangi, sem er þægindi en ekki frátekning. Leyfðu varanleikaskránni ekki að verða eignaskrá, því hún breytist með tengingarsögu en ekki stefnu.

Forgangur úthlutunar ræður því hver vinnur

Handbókin skjalfestir röð: skýr úthlutun sem mynduð er meðan á client-connect stendur getur tekið gildi fyrir client-config-dir færslu, sem aftur kemur fyrir venjulega úthlutun úr lauginni. Þessi röð útskýrir flestar skýrslur um „festa vistfangið virkaði ekki“. Hún þýðir líka að hreyfanlegur úthlutandi sem skrifar stillingu á hverja setu getur hljóðlega hnekkt fastri skrá sem þú taldir vera valdbera.

Veldu eitt lag sem á úthlutanirnar og gerðu hin skrifvarin. Tvö lög sem bæði segjast ákveða framleiða úthlutanir sem ráðast af tímasetningu.

Hreyfanlegur úthlutandi þarf sama líkan

Client-connect samþætting sem úthlutar vistföngum á hverja setu er lítill úthlutandi með venjuleg úthlutandavandamál. Hann verður að sannreyna auðkenni beiðandans, taka frá vistfang á atómlegan hátt, gefa aðeins út studda úttakið fyrir hverja tengingu og sleppa frátekningunni við aftengingu eða bilun. Samtímis beiðnir þurfa lás eða gagnagrunnsskilyrði, ekki lesa-síðan-skrifa röð. Án hreinsunar lekur laugin vistföngum þar til endurræst er.

Haltu stöðu úthlutandans þar sem næsti rekstraraðili getur lesið hana, og skráðu ákvörðunina auðkenni-í-vistfang en ekki aðeins vistfangið.

Ákveddu hvort vistfangið er stefna eða þægindi

Ef eldveggjarregla eða leið leyfir umferð frá einu gönguvistfangi, þá tekur vistfangið þátt í aðgangsstefnunni og endurúthlutun erfir það leyfi. Samræmdu lífsferil auðkennis, vistfangs og eldveggjar, eða bundu regluna við eitthvað sem ekki er hægt að endurúthluta. Stöðug vistföng gera stillinguna læsilega; þau koma ekki í stað auðkenningar.

Skrifaðu áætlunina sem eignaskrá með eiganda fyrir hverja færslu, og farðu yfir hana þegar tæki er tekið úr notkun. Ónotaða frátekningin er sú sem er endurnotuð fyrir slysni.

Tengdir greinar