OpenVPN client-connect кука: каде всушност оди вашата адреса

Враќањето адреса од 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 и останатите. Третирајте ги сите како низи од надвор од серверот, никогаш како делови од shell.

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

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

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

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

Топологијата одредува што значи 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 може да пишува, а демонот не, ја претвора секоја врска во одбивање со грешка за дозволи закопана неколку реда подолу во дневникот.

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