Стабилне OpenVPN адресе треба да прате идентитет, а не изворни IP

Планови адреса који кажу „ово преносно рачунаро добија 10.90.0.10“ заправо су изјаве о идентитету: који оверени уређај сме да држи ту адресу. Тренутни јавни IP тог уређаја готово да нема везе с тим, јер NAT и роаминг га мењају без промене тога ко је корисник. Изградња плана на изворној адреси ствара правила која се ломе на првој хотелској мрежи. Изградња на овереном идентитету ствара план који преживљава путовања.

Почните од онога што сервер може да провери, затим одлучите чему адреса служи.

Изаберите кључ идентитета пре адресе

Засебан клијентски сертификат по уређају даје серверу стабилан, проверљив кључ за сваког члана, што је најчистија основа за статичну доделу. Поставка која користи аутентификацију по кориснику може уместо тога да се ослони на корисничко име, све док избор конфигурације следи исто поље. Мешање двају модела ствара доделе које одговарају сертификату за једног клијента и корисничком имену за другог, и нико не може да предвиди који ће победити. Одлучите који кључ план користи пре него што напишете и једну резервацију.

Уз duplicate-cn неколико истовремених сесија може да представи исто заједничко име, па једна причвршћена адреса не може да их идентификује појединачно. То је својство модела идентитета, а не нешто што бољи план адреса може да исправи.

Резервишите адресе изван динамичког распона

У мрежи с топологијом подмреже као што је 10.90.0.0/24, задржите ниже адресе за именоване чланове и ставите динамички пул у одвојен распон. Додела за причвршћеног члана изгледа овако ifconfig-push 10.90.0.10 255.255.255.0 у датотеци коју сервер бира за тај идентитет. Други аргумент значи нешто друго под net30, па пример није неутралан према топологији. Прочитајте топологију пре него што га копирате.

Трајност пула бележи недавне закупе и склона је враћању исте адресе, што је погодност, а не резервација. Не дозволите да датотека трајности постане евиденција власништва, јер се мења с историјом веза, а не с политиком.

Приоритет доделе одлучује ко побеђује

Приручник документује редослед: експлицитна додела створена током client-connect може да ступи на снагу пре уноса у client-config-dir, који заузврат претходи уобичајеној подели из пула. Тај редослед објашњава већину извештаја „причвршћена адреса није примењена“. То такође значи да динамички алокатор који пише конфигурацију по сесији може тихо да надјача статичну датотеку коју сте сматрали меродавном.

Изаберите један слој који поседује доделе и учините остале само за читање. Два слоја која оба тврде да одлучују стварају доделе које зависе од времена.

Динамичком алокатору је потребан исти модел

Интеграција client-connect која дели адресе по сесији мали је алокатор с уобичајеним проблемима алокатора. Мора да валидира идентитет подносиоца захтева, атомски резервише адресу, исписује само подржани излаз по вези и ослободи резервацију при прекиду или грешци. Истовремени захтеви захтевају брану или ограничење базе података, а не низ читања па писања. Без чишћења, пул губи адресе до поновног покретања.

Држите стање алокатора тамо где следећи оператер може да га прочита и бележите одлуку идентитет-према-адреси, а не само адресу.

Одлучите да ли је адреса политика или погодност

Ако правило заштитног зида или рута дозвољава саобраћај са једне адресе тунела, онда адреса учествује у политици приступа и поновна додела наслеђује то дозволење. Ускладите животни циклус идентитета, адресе и заштитног зида или вежите правило за нешто што се не може поново доделити. Стабилно адресирање чини конфигурацију читљивом; оно не замењује аутентификацију.

Напишите план као инвентар са власником по ставци, затим га прегледајте када уређај буде повучен из употребе. Неискоришћена резервација је она која се случајно поново употреби.