Статичен 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

Проверете адреса срещу всичко друго, което може да го притежава: друго явно назначение, диапазона на динамичния пул и всеки статичен маршрут, който предполага фиксиран хост. Адрес, който се припокрива с пула, ще работи, докато пулът не го даде на някой друг, и този отказ ще изглежда случаен.

Проверете резултата при ново свързване

Съществуващата сесия запазва адреса, който ѝ е даден, затова единственият смислен тест е нова връзка. Прекъснете клиента, свържете го отново и прочетете адреса, който действително е получил, заедно с маршрутите, дошли с него. Ако адресът все още е динамичен, назначението не е приложено и следващата стъпка е търсене в конфигурацията, а не още една редакция на файла с историята.

Дръжте доказателствата заедно: името на клиента, файла, който съвпадна, зададения адрес и пула, от който е дошъл.

Накрая, фиксираният адрес на тунела не е идентификационни данни на устройството. Той отбелязва място в плана на адресите, докато удостоверяването все още почива на сертификата и акаунта. Объркването на двете превръща конфликта на адреси в предположение за сигурност, което никой не е записал.