Stabilni naslovi OpenVPN morajo slediti identiteto, ne izvornega IP

Načrti naslovov, ki pravijo »ta prenosnik dobi 10.90.0.10«, so v resnici izjave o identiteti: katera overjena naprava lahko ima ta naslov. Trenutni javni IP te naprave s tem skoraj nima nič skupnega, ker NAT in gostovanje ga spreminjata, ne da bi spremenila, kdo je uporabnik. Gradnja načrta na izvornem naslovu ustvari pravila, ki se zlomijo v prvem hotelskem omrežju. Gradnja na overjeni identiteti ustvari načrt, ki preživi potovanja.

Začnite s tem, kar lahko strežnik preveri, nato odločite, čemu je naslov namenjen.

Izberite ključ identitete pred naslovom

Ločeno potrdilo odjemalca za vsako napravo da strežniku stabilen, preverljiv ključ za vsakega člana, kar je najčistejša osnova za statično dodelitev. Namestitev z overjanjem po uporabniku se lahko namesto tega opre na uporabniško ime, če izbira konfiguracije sledi istemu polju. Mešanje obeh modelov ustvari dodelitve, ki se ujemajo s potrdilom pri enem odjemalcu in z uporabniškim imenom pri drugem, in nihče ne more predvideti, kateri bo zmagal. Odločite, kateri ključ uporablja načrt, preden napišete eno samo rezervacijo.

S duplicate-cn lahko več hkratnih sej predstavi isto skupno ime, zato en pripet naslov ne more prepoznati vsake posebej. To je lastnost modela identitete, ne nekaj, kar bi boljši načrt naslovov lahko popravil.

Rezervirajte naslove zunaj dinamičnega obsega

V omrežju s topologijo podomrežja, kot je 10.90.0.0/24, obdržite nizke naslove za imenovane člane in dinamični bazen postavite v ločen obseg. Dodelitev za pripetega člana je videti takole ifconfig-push 10.90.0.10 255.255.255.0 v datoteki, ki jo strežnik izbere za to identiteto. Drugi argument pod net30 pomeni nekaj drugega, zato primer ni nevtralen glede na topologijo. Preberite topologijo, preden ga kopirate.

Trajnost bazena beleži nedavne najeme in rada vrne isti naslov, kar je udobje in ne rezervacija. Ne dovolite, da bi datoteka trajnosti postala evidenca lastništva, ker se spreminja z zgodovino povezav, ne s politiko.

Prednost dodelitve odloči, kdo zmaga

Priročnik dokumentira vrstni red: izrecna dodelitev, ustvarjena med client-connect, lahko začne veljati pred vnosom client-config-dir, ki pa je pred običajno dodelitvijo iz bazena. Ta vrstni red pojasni večino poročil »pripeti naslov se ni uporabil«. Pomeni tudi, da lahko dinamični razdeljevalnik, ki piše konfiguracijo za vsako sejo, tiho prepiše statično datoteko, ki ste jo imeli za avtoritativno.

Izberite eno plast, ki ima v lasti dodelitve, druge pa naredite samo za branje. Dve plasti, ki obe trdita, da odločata, ustvarjata dodelitve, odvisne od časa.

Dinamični razdeljevalnik potrebuje isti model

Integracija client-connect, ki deli naslove za vsako sejo, je majhen razdeljevalnik z običajnimi težavami razdeljevalnika. Preveriti mora identiteto prosilca, atomsko rezervirati naslov, oddati samo podprt izhod za povezavo in sprostiti rezervacijo ob prekinitvi ali napaki. Hkratne zahteve potrebujejo zaklep ali omejitev baze podatkov, ne zaporedja branja in nato pisanja. Brez čiščenja bazen pušča naslove do ponovnega zagona.

Hranite stanje razdeljevalnika tam, kjer ga lahko naslednji upravljavec prebere, in beležite odločitev identiteta-v-naslov, ne le naslova.

Odločite, ali je naslov politika ali udobje

Če pravilo požarnega zidu ali pot dovoljuje promet z enega naslova tunela, potem naslov sodeluje v politiki dostopa in ponovna dodelitev podeduje to dovoljenje. Uskladite življenjski cikel identitete, naslova in požarnega zidu ali pravilo vežite na nekaj, česar ni mogoče ponovno dodeliti. Stabilno naslavljanje naredi konfiguracijo berljivo; ne nadomesti overjanja.

Napišite načrt kot popis z lastnikom pri vsakem vnosu, nato pa ga pregledajte, ko se naprava umakne iz uporabe. Neuporabljena rezervacija je tista, ki se pomotoma znova uporabi.