Stabilne OpenVPN adrese treba da prate identitet, a ne izvorni IP

Planovi adresa koji kažu „ovaj laptop dobija 10.90.0.10“ zapravo su izjave o identitetu: koji ovjereni uređaj smije držati tu adresu. Trenutni javni IP tog uređaja gotovo da nema veze s tim, jer NAT i roaming ga mijenjaju bez promjene toga ko 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 server može provjeriti, zatim odlučite čemu adresa služi.

Odaberite ključ identiteta prije adrese

Zasebni klijentski certifikat po uređaju daje serveru stabilan, provjerljiv ključ za svakog člana, što je najčišća osnova za statičnu dodjelu. Postavka koja koristi autentifikaciju po korisniku može se umjesto toga osloniti na korisničko ime, sve dok izbor konfiguracije slijedi isto polje. Miješanje dva modela stvara dodjele koje odgovaraju certifikatu za jednog klijenta i korisničkom imenu za drugog, i niko ne može predvidjeti ko će pobijediti. Odlučite koji ključ plan koristi prije nego što napišete ijednu rezervaciju.

Uz duplicate-cn nekoliko istovremenih sesija može predstaviti isto zajedničko ime, pa jedna prikovana adresa ne može ih pojedinačno identificirati. To je svojstvo modela identiteta, a ne nešto što bolji plan adresa može ispraviti.

Rezervišite 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 pul u odvojen raspon. Dodjela za prikovanog člana izgleda ovako ifconfig-push 10.90.0.10 255.255.255.0 u datoteci koju server odabere 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 pula 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 historijom veza, a ne s politikom.

Prioritet dodjele odlučuje ko pobjeđuje

Priručnik dokumentuje redoslijed: eksplicitna dodjela stvorena tokom client-connect može stupiti na snagu prije unosa u client-config-dir, koji pak prethodi običnoj dodjeli iz pula. Taj redoslijed objašnjava većinu izvještaja „prikovana adresa se nije primijenila“. 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 zavise od vremena.

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 podnosioca zahtjeva, atomski rezervisati adresu, emitovati samo podržani izlaz po vezi i osloboditi rezervaciju pri prekidu ili grešci. Istovremeni zahtjevi trebaju bravu ili ograničenje baze podataka, a ne slijed čitanja pa pisanja. Bez čišćenja, pul 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 saobraćaj s jedne adrese tunela, tada adresa sudjeluje u politici pristupa i ponovna dodjela nasljeđuje to dopuštenje. Uskladite životni ciklus identiteta, adrese i firewall-a 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.