Adresplannen dy’t sizze ‘dizze laptop krijt 10.90.0.10’ binne eins útspraken oer identiteit: hokker ferifiearre apparaat dat adres hawwe mei. It hjoeddeiske publike IP fan dat apparaat hat der hast neat mei te dwaan, om’t NAT en roaming it feroarje sûnder te feroarjen wa’t de brûker is. It plan op it boarne-adres bouwe jout regels dy’t by it earste hotelnetwurk brekke. It op de ferifiearre identiteit bouwe jout in plan dat reizgjen oerlibbet.

Begjin by wat de server ferifiearje kin, en beslút dan wêr’t it adres foar is.

Kies de identiteitskaai foar it adres

In apart kliïntsertifikaat per apparaat jout de server in stabile, ferifiearbere kaai foar elk lid, wat de skjinste basis foar in statyske tawizing is. In útrulling mei ferifikaasje per brûker kin ynstee op de brûkersnamme stypje, salang’t de konfiguraasjekarring itselde fjild folget. It mingjen fan de beide modellen jout tawizings dy’t foar de iene kliïnt by in sertifikaat passe en foar in oare by in brûkersnamme, en nimmen kin foarsizze hokker wint. Beslút hokker kaai it plan brûkt foar’t jo ien inkele reservearring skriuwe.

Mei duplicate-cn kinne ferskate tagelyk aktive sesjes deselde mienskiplike namme presintearje, sadat ien fêstset adres se net yndividueel identifisearje kin. Dat is in eigenskip fan it identiteitsmodel, net eat dat in better adresplan reparearje kin.

Reservearje adressen bûten it dynamyske berik

Yn in netwurk mei subnet-topology lykas 10.90.0.0/24 hâldt jo de lege adressen foar neamde leden en sette jo de dynamyske pool yn in apart berik. In tawizing foar in fêstset lid sjocht der sa út ifconfig-push 10.90.0.10 255.255.255.0 yn it bestân dat de server foar dy identiteit kiest. It twadde argumint betsjut ûnder net30 wat oars, dus it foarbyld is net topology-neutraal. Lês de topology foar’t jo it kopiearje.

Poolpersistinsje registrearret resinte leases en hat de oanstriid itselde adres werom te jaan, wat in gemak is en gjin reservearring. Lit it persistinsjebestân net it register fan eigendom wurde, om’t it feroaret mei de ferbiningsskiednis en net mei it belied.

Tawizingsprioriteit beslissend wa’t wint

De hantlieding dokumintearret in oarder: in eksplisite tawizing dy’t ûnder client-connect oanmakke is, kin foar in client-config-dir-ynstap yn wurking trede, dy’t op syn beurt foar gewoane pooltawizing komt. Dy oarder ferklearret de measte rapporten ‘it fêstsette adres waard net tapast’. It betsjut ek dat in dynamyske taskenner dy’t konfiguraasje per sesje skriuwt, stilwei in statysk bestân oerskriuwe kin dat jo as gesachhawwend beskôgen.

Kies ien laach om tawizings te besitten en meitsje de oaren allinne-lêsber. Twa lagen dy’t beide beweare te beslissen, jouwe tawizings dy’t fan timing ôfhingje.

In dynamyske taskenner hat itselde model nedich

In client-connect-ynbou dy’t adressen per sesje útdielt is in lytse taskenner mei de gewoane taskennerproblemen. Hy moat de oanfreegjende identiteit ferifiearje, in adres atomysk reservearje, allinne de stipe útfier per ferbining leverje en de reservearring by ôfbrekken of mislearring frijlitte. Tagelyk aktive oanfragen hawwe in slot of in databankbeheining nedich, net in lês-dan-skriuw-sekwinsje. Sûnder opromming lekket de pool adressen oant in werstart.

Hâld de tastân fan de taskenner wêr’t de folgjende operator it lêze kin, en log it beslút identiteit-nei-adres ynstee fan allinne it adres.

Beslút oft it adres belied of gemak is

As in firewallregel of in rûte ferkear fan ien tunneladres talit, dan docht it adres mei oan it tagongsbelied en in weriening erft dy tastimming. Koördinearje de libbenssyklus fan identiteit, adres en firewall, of koppelje de regel oan eat dat net wer tawiisd wurde kin. Stabile adressearring makket de konfiguraasje lêsber; it ferfangt gjin ferifikaasje.

Skriuw it plan as in ynventaris mei in eigner per ynstap, en beoardielje it as in apparaat út tsjinst nommen wurdt. De ûnbrûkte reservearring is dejinge dy’t by ûngelok wer brûkt wurdt.

Relatearre artikelen