Статычны IP для кожнага кліента OpenVPN: ifconfig-push, а не ipp.txt

Рэдагаванне радка ў ipp.txt выглядае як рэзерваванне адраса, але ім не з'яўляецца. Гэты файл, названы ifconfig-pool-persist, запісвае, які адрас агульнае імя мела апошні раз, каб пул мог вярнуць той жа адрас, калі гэта зручна. Нішто ў ім не прывязвае наступнае злучэнне да гэтага нумара.

Выканайце наступныя праверкі па парадку. Кожная з іх або пацвярджае механізм, або кажа спыніцца і выправіць уваходныя даныя.

Для чаго патрэбен файл захавання

Файл існуе, каб захоўваць адрасы стабільнымі паміж перазапускамі, што робіць перападключэнні зручнейшымі, а журналы — чытальнейшымі. Ён чытаецца як гісторыя і запісваецца як гісторыя, а шлях размеркавання застаецца вольным выбраць іншы адрас, калі падказка не падыходзіць: іншы пул, канфліктнае прызначэнне або кліент, які прыйшоў пасля запаўнення пула. Таму ручная праўка можа выглядаць бездакорна ў файле і нічога не змяняць у злучэнні. Стаўцеся да яго як да кэша мінулых рашэнняў, а не як да крыніцы палітыкі.

Калі вам патрэбен пэўны адрас для пэўнага кліента, дакументаваны механізм — ifconfig-push, і ён належыць канфігурацыі, якая валодае гэтым кліентам.

Праверце, што выбраны правільны кліент

Яўнае прызначэнне шукаецца па агульным імені кліента, таму файл, названы для няправільнай асобы, проста ніколі не чытаецца. Пацвердзіце, што сервер лічыць імем гэтага кліента, асабліва там, дзе username-as-common-name змяняе яго пасля аўтэнтыфікацыі. Затым пацвердзіце, што імя файла дакладна адпавядае гэтаму значэнню, уключаючы рэгістр.

Падумайце пра паралельнасць, пакуль вы тут. Калі duplicate-cn дазволены, некалькі прылад могуць прадставіць адну і тую ж асобу, і адзін фіксаваны адрас не можа быць унікальным для ўсіх іх. Вырашыце, ці варта адмаўляцца ад паралельных сесій для гэтай асобы дзеля фіксаванага адраса, бо гэтыя два патрабаванні нельга задаволіць адначасова.

Праверце, што лікі адпавядаюць тапалогіі

Сэнс аргументаў залежыць ад тапалогіі тунэля, і менавіта тут скапіяваны прыклад наносіць найбольшую шкоду. У старэйшай схеме net30 кожны кліент займае блок з чатырох адрасоў, таму push падае пару адрасоў. У тапалогіі падсеткі кліент атрымлівае адзін адрас плюс маску пула, і форма пары няправільная. Прачытайце тапалогію з працуючай канфігурацыі перад запісам радка.

# /etc/openvpn/ccd/partner-a   (subnet topology)
ifconfig-push 10.44.0.61 255.255.255.0

Праверце адрас супраць усяго іншага, што можа ім валодаць: іншае яўнае прызначэнне, дыяпазон дынамічнага пула і любы статычны маршрут, які мяркуе фіксаваны хост. Адрас, які перасякаецца з пулам, будзе працаваць, пакуль пул не аддасць яго камусьці іншаму, і гэты збой будзе выглядаць выпадковым.

Праверце вынік на новым злучэнні

Існуючая сесія захоўвае адрас, які ёй далі, таму адзіны значны тэст — новае злучэнне. Адключыце кліента, падключыцеся зноў і прачытайце адрас, які ён фактычна атрымаў, разам з маршрутамі, што прыйшлі з ім. Калі адрас па-ранейшаму дынамічны, прызначэнне не прымянілася, і наступны крок — пошук у канфігурацыі, а не чарговая праўка файла гісторыі.

Трымайце доказы разам: імя кліента, файл, які супаў, прызначаны адрас і пул, з якога ён прыйшоў.

Нарэшце, фіксаваны адрас тунэля — гэта не ўліковыя даныя прылады. Ён пазначае месца ў плане адрасоў, а аўтэнтыфікацыя па-ранейшаму абапіраецца на сертыфікат і ўліковы запіс. Блытаніна паміж двума ператварае канфлікт адрасоў у меркаванне бяспекі, якога ніхто не запісаў.