Stabilaj OpenVPN-adresoj sekvu identecon, ne fontan IP
Statika adreso estas aserto pri identeco, ne pri fonta IP. Elektu la ŝlosilon, tenu rezervojn ekster la naĝejo, poste elektu la posedanton de la asigno.
Adresaj planoj, kiuj diras «ĉi tiu tekkomputilo ricevas 10.90.0.10», fakte estas asertoj pri identeco: kiu aŭtentigita aparato rajtas teni tiun adreson. La nuna publika IP de tiu aparato preskaŭ nenion rilatas al tio, ĉar NAT kaj migrado ŝanĝas ĝin sen ŝanĝi, kiu estas la uzanto. Konstrui la planon sur la fonta adreso produktas regulojn, kiuj rompiĝas en la unua hotela reto. Konstrui ĝin sur la aŭtentigita identeco produktas planon, kiu postvivas vojaĝojn.
Komencu de tio, kion la servilo povas kontroli, poste decidu, por kio la adreso estas.
Elektu la identecan ŝlosilon antaŭ la adreso
Aparta klienta atestilo por ĉiu aparato donas al la servilo stabilan, kontroleblan ŝlosilon por ĉiu membro, kio estas la plej pura bazo por statika asigno. Instalaĵo uzanta aŭtentigon laŭ uzanto povas anstataŭe baziĝi sur la uzantnomo, kondiĉe ke la elekto de agordo sekvas la saman kampon. Miksi la du modelojn produktas asignojn, kiuj kongruas kun atestilo por unu kliento kaj kun uzantnomo por alia, kaj neniu povas antaŭdiri, kiu venkos. Decidu, kiun ŝlosilon la plano uzas, antaŭ ol skribi eĉ unu rezervon.
Kun duplicate-cn pluraj samtempaj seancoj povas prezenti la saman komunan nomon, do unu fiksita adreso ne povas identigi ilin individue. Tio estas eco de la identeca modelo, ne io, kion pli bona adresa plano povas ripari.
Rezervu adresojn ekster la dinamika gamo
En reto kun subreta topologio kiel 10.90.0.0/24, tenu la malaltajn adresojn por nomitaj membroj kaj metu la dinamikan naĝejon en apartan gamon. Asigno por fiksita membro aspektas tiel ifconfig-push 10.90.0.10 255.255.255.0 en la dosiero, kiun la servilo elektas por tiu identeco. La dua argumento signifas ion alian sub net30, do la ekzemplo ne estas topologie neŭtrala. Legu la topologion antaŭ ol kopii ĝin.
Naĝeja daŭreco registras lastatempajn luojn kaj emas redoni la saman adreson, kio estas oportuneco, ne rezervo. Ne lasu la daŭrecan dosieron fariĝi la registro de posedo, ĉar ĝi ŝanĝiĝas kun la konekta historio, ne kun la politiko.
Asigna prioritato decidas, kiu venkas
La manlibro dokumentas ordon: eksplicita asigno generita dum client-connect povas ekvalidi antaŭ client-config-dir-ero, kiu siavice antaŭas ordinaran naĝejan disdonon. Tiu ordo klarigas la plej multajn raportojn «la fiksita adreso ne aplikiĝis». Ĝi ankaŭ signifas, ke dinamika asignilo, kiu skribas agordon por ĉiu seanco, povas silente superregi statikan dosieron, kiun vi opiniis aŭtoritata.
Elektu unu tavolon, kiu posedu la asignojn, kaj faru la aliajn nurlegeblaj. Du tavoloj, kiuj ambaŭ asertas decidi, produktas asignojn dependajn de tempo.
Dinamika asignilo bezonas la saman modelon
Integraĵo client-connect, kiu disdonas adresojn por ĉiu seanco, estas malgranda asignilo kun la kutimaj asignilaj problemoj. Ĝi devas kontroli la petantan identecon, rezervi adreson atome, elsendi nur la subtenatan eliron por konekto kaj liberigi la rezervon ĉe malkonekto aŭ fiasko. Samtempaj petoj bezonas ŝlosilon aŭ datumbazan limigon, ne sinsekvon legi-poste-skribi. Sen purigado la naĝejo perdas adresojn ĝis restarto.
Tenu la staton de la asignilo tie, kie la sekva operatoro povas legi ĝin, kaj registru la decidon identeco-al-adreso, ne nur la adreson.
Decidu, ĉu la adreso estas politiko aŭ oportuneco
Se fajroŝirma regulo aŭ itinero permesas trafikon de unu tunela adreso, tiam la adreso partoprenas en la alira politiko kaj reasigno heredas tiun permeson. Kunordigu la vivciklon de identeco, adreso kaj fajroŝirmilo, aŭ ligi la regulon al io, kio ne povas esti reasignita. Stabila adresado faras la agordon legebla; ĝi ne anstataŭas aŭtentigon.
Skribu la planon kiel inventaron kun posedanto por ĉiu ero, poste reviziu ĝin, kiam aparato estas retirigita. La neuzita rezervo estas tiu, kiu estas hazarde reuzita.