Враћање адресе из client-connect скрипте изгледа као да треба да постави IP адресу клијента. Али не поставља је: једини канал куке ка серверу је привремена датотека чија путања стиже као последњи аргумент скрипте, а адреса мора да се запише тамо у синтакси ifconfig-push. Скрипта која штампа адресу или излази са нулом без ичега записаног ствара повезаног клијента са адресом из базена, а серверски дневник изгледа потпуно здраво.

Забуна је разумљива, јер неколико других кука заиста одговара преко излазних кодова или променљивих окружења. Ова има свој уговор, а уговор почиње именом датотеке.

Кука записује датотеку, не повратну вредност

Декларација је два реда: script-security 2 да дозволи позив, затим client-connect /etc/openvpn/server/assign-address.sh. Када се клијент аутентификује, сервер извршава ту скрипту са генерисаном путањом датотеке додатом као последњи аргумент, која је $1 само ако декларација не прослеђује сопствене додатне аргументе. Све што се примењује на тог клијента иде у ту датотеку као обичне директиве, једна по реду, тачно како би изгледале у конфигурацији. Омотач који додаје сопствене параметре помера позицију, а класичан симптом је скрипта која пише на путању која изгледа као --verbose.

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

Две директиве заслужују пажњу јер делују на све остало. ifconfig-push фиксира адресу, док послата route говори клијенту шта је доступно кроз тунел; вратите прву и заборавите другу и добијате клијента са адресом и без места где да иде. Редослед у датотеци није важан, али потпуност јесте. Кука која шаље руту за префикс до којег ниједан партнер не може да стигне је иста грешка виђена са друге стране.

Улази стижу преко променљивих окружења: common_name, trusted_ip, ifconfig_pool_remote_ip и осталих. Третирајте их све као низове споља, никада као делове љуске.

Мапирање адреса је политика, не аритметика

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

Ко контролише име, контролише адресу, зато одлучите шта common_name заиста представља у овом распоређивању. Са укљученим username-as-common-name, идентитет је пријава, а не субјекат сертификата. Никада не прослеђујте ту вредност у процену љуске и никада не дозволите клијенту да утиче на путању датотеке.

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

Топологија одређује шта значи ifconfig-push

Са topology subnet на 10.77.0.0/24, ifconfig-push 10.77.0.20 255.255.255.0 је адреса плус њена мрежна маска. Под topology net30 други аргумент уопште није маска већ адреса партнера, па копирање облика подмреже на net30 сервер даје клијента који се повезује и не може да пропушта саобраћај. Мењајте топологију намерно, никада зато што пример треба да изгледа доследно. Сервер који већ ради на net30 има живе клијенте на старом адресирању, па је пребацивање миграција са прозором за одржавање, а не измена једног реда.

Статичне адресе морају да стоје изван динамичког базена и изван сваке друге статичне доделе, укључујући оне које дају обичне client-config-dir датотеке. Ако два механизма могу да произведу исту адресу за различите клијенте, један од њих ће то на крају и учинити.

Тестирајте четири случаја пре него што му поверујете

Покрените исте провере на мапираном идентитету, немапираном, поновном повезивању и симулираном отказу регистра. openvpn --config client.ovpn --verb 4 приказује додељену адресу у push одговору, а на серверу grep -A2 PUSH_REPLY /var/log/openvpn/openvpn.log потврђује шта је заиста послато. За немапирани идентитет очекивани резултат је одбијена веза, а не адреса из базена.

Затим прегледајте директоријум у који демон записује те привремене датотеке. Скрипта се извршава у сниженом контексту услуге, па путања у коју root може да пише, а демон не, претвара сваку везу у одбијање са грешком дозвола закопаном неколико редова ниже у дневнику.

Додела није ауторизација: фиксирана адреса и даље не даје приступ сваком одредишту иза сервера. Држите политику рутирања и заштитног зида у свом слоју и проверите је према адреси коју сте управо фиксирали.

Повезани чланци