Статична OpenVPN IP по клиент: 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

Проверете ја адресата против сѐ друго што би можело да ја поседува: друга експлицитна доделување, опсегот на динамичкиот базен и секоја статична рута што претпоставува фиксен домаќин. Адреса што се преклопува со базенот ќе работи додека базенот не ја даде на некој друг, и тој неуспех ќе изгледа случајно.

Проверете го резултатот на нова врска

Постојната сесија ја задржува адресата што ѝ е дадена, така што единствениот значаен тест е нова врска. Исклучете го клиентот, поврзете се повторно и прочитајте ја адресата што навистина ја добил заедно со рутите што пристигнале со неа. Ако адресата е сѐ уште динамичка, доделувањето не е применето, и следниот чекор е пребарување во конфигурацијата, а не уште едно уредување на датотеката со историја.

Чувајте ги доказите заедно: името на клиентот, датотеката што се совпадна, доделената адреса и базенот од кој дојде.

Конечно, фиксната адреса на тунелот не е идентификациско средство на уредот. Таа означува место во планот на адреси, додека автентикацијата сѐ уште се потпира на сертификатот и сметката. Мешањето на двете претвора конфликт на адреси во безбедносна претпоставка што никој не ја запишал.