Stabilne OpenVPN adrese trebaju slijediti identitet, a ne izvorni IP
Statična adresa izjava je o identitetu, a ne o izvornom IP-u. Odaberite ključ, držite rezervacije izvan poola, zatim odaberite vlasnika dodjele.
Planovi adresa koji kažu „ovo prijenosno računalo dobiva 10.90.0.10“ zapravo su izjave o identitetu: koji ovjereni uređaj smije držati tu adresu. Trenutačni javni IP tog uređaja gotovo da nema veze s tim, jer NAT i roaming mijenjaju ga bez promjene toga tko je korisnik. Izgradnja plana na izvornoj adresi stvara pravila koja se lome na prvoj hotelskoj mreži. Izgradnja na ovjerenom identitetu stvara plan koji preživljava putovanja.
Pođite od onoga što poslužitelj može provjeriti, zatim odlučite čemu adresa služi.
Odaberite ključ identiteta prije adrese
Zasebni klijentski certifikat po uređaju daje poslužitelju stabilan, provjerljiv ključ za svakog člana, što je najčišća osnova za statičnu dodjelu. Postava koja koristi autentifikaciju po korisniku može se umjesto toga osloniti na korisničko ime, sve dok odabir konfiguracije slijedi isto polje. Miješanje dvaju modela stvara dodjele koje odgovaraju certifikatu za jednog klijenta i korisničkom imenu za drugoga, i nitko ne može predvidjeti koji će pobijediti. Odlučite koji ključ plan koristi prije nego što napišete ijednu rezervaciju.
Uz duplicate-cn nekoliko istodobnih sesija može predstaviti isto zajedničko ime, pa jedna prikvačena adresa ne može ih pojedinačno identificirati. To je svojstvo modela identiteta, a ne nešto što bolji plan adresa može ispraviti.
Rezervirajte adrese izvan dinamičkog raspona
U mreži s topologijom podmreže kao što je 10.90.0.0/24, zadržite niske adrese za imenovane članove i stavite dinamički pool u odvojen raspon. Dodjela za prikvačenog člana izgleda ovako ifconfig-push 10.90.0.10 255.255.255.0 u datoteci koju poslužitelj odabire za taj identitet. Drugi argument znači nešto drugo pod net30, pa primjer nije neutralan prema topologiji. Pročitajte topologiju prije nego što ga kopirate.
Trajnost poola bilježi nedavne zakupnine i sklona je vraćanju iste adrese, što je pogodnost, a ne rezervacija. Ne dopustite da datoteka trajnosti postane evidencija vlasništva, jer se mijenja s poviješću veza, a ne s politikom.
Prioritet dodjele odlučuje tko pobjeđuje
Priručnik dokumentira redoslijed: eksplicitna dodjela stvorena tijekom client-connect može stupiti na snagu prije unosa u client-config-dir, koji pak prethodi običnoj dodjeli iz poola. Taj redoslijed objašnjava većinu izvještaja „prikvačena adresa nije primijenjena“. Također znači da dinamički alokator koji piše konfiguraciju po sesiji može tiho nadjačati statičnu datoteku koju ste smatrali mjerodavnom.
Odaberite jedan sloj koji posjeduje dodjele i učinite ostale samo za čitanje. Dva sloja koja oba tvrde da odlučuju stvaraju dodjele koje ovise o vremenu.
Dinamičkom alokatoru treba isti model
Integracija client-connect koja dijeli adrese po sesiji mali je alokator s uobičajenim problemima alokatora. Mora validirati identitet podnositelja zahtjeva, atomski rezervirati adresu, ispisivati samo podržani izlaz po vezi i osloboditi rezervaciju pri prekidu ili pogrešci. Istodobni zahtjevi trebaju bravu ili ograničenje baze podataka, a ne slijed čitanja pa pisanja. Bez čišćenja pool curi adrese do ponovnog pokretanja.
Držite stanje alokatora tamo gdje ga sljedeći operater može pročitati i bilježite odluku identitet-prema-adresi, a ne samo adresu.
Odlučite je li adresa politika ili pogodnost
Ako firewall pravilo ili ruta dopušta promet s jedne adrese tunela, tada adresa sudjeluje u politici pristupa i ponovna dodjela nasljeđuje to dopuštenje. Uskladite životni ciklus identiteta, adrese i firewalla ili vežite pravilo za nešto što se ne može ponovno dodijeliti. Stabilno adresiranje čini konfiguraciju čitljivom; ono ne zamjenjuje autentifikaciju.
Napišite plan kao inventar s vlasnikom po stavci, zatim ga pregledajte kada uređaj bude povučen iz upotrebe. Neiskorištena rezervacija je ona koja se slučajno ponovno upotrijebi.