FreeBind наспроти After=: поврзување systemd сокет со VPN адреса

При подигнување, сокет единица што врзува фиксна VPN адреса може да не успее пред тунелот да ѝ ја додели, и услугата зад неа никогаш не стартува. Два прекинувачи изгледаат како поправки и решаваат различни половини од тој проблем. FreeBind му овозможува на systemd да го создаде слушачот додека адресата сѐ уште недостасува. After= само ги подредува задачите, па менува кога работите почнуваат, но не прави адресата да пристигне порано.

Два различни проблема, два различни прекинувачи

Првиот проблем е неуспех при врзување: јадрото одбива слушање на адреса што домаќинот не ја поседува, па сокет единицата веднаш не успева и услугата никогаш не се активира. Вториот проблем е неуспех при подготвеност: адресата на крајот постои, но нешто се обидува да ја користи пред тунелот да пренесува сообраќај. FreeBind го решава првиот и не прави ништо за вториот. Директивите за редослед не решаваат ниту еден директно, бидејќи тие само одлучуваат што по кој ред започнува. Именувањето на неуспехот што навистина го имате е целата одлука.

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

FreeBind: слушачот постои пред адресата

FreeBind му кажува на јадрото да дозволи врзување на нелокална адреса, за да може systemd да го создаде слушачкиот сокет при подигнување и да му го предаде на апликацијата секогаш кога апликацијата стартува. Тоа е смислата на активирањето преку сокет и причината зошто сокетот може да ја надживее услугата зад него.

[Socket]
ListenStream=
ListenStream=10.8.0.1:8443
FreeBind=yes

Празната додела ги брише записите за слушање наследени од единицата на добавувачот пред да се додаде новиот, што спречува преостанат wildcard слушач да одговара на секој интерфејс. Заменете ја адресата и портата со свои и проверете ја ефективната единица, а не само drop-in датотеката. Користете drop-in под името на единицата наместо да уредувате датотека од пакетот на место, бидејќи следното ажурирање на пакетот ќе го препише уредувањето и нема да остави никаква трага од намерата. Потоа применете го преку постапката за повторно вчитување и рестартирање што ја очекува сокет единицата.

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

After= и Wants=: редоследот не е подготвеност

Редоследот и барањето се одделни оски, а нивното мешање создава единици што започнуваат по правилен редослед и сепак не успеваат. After=vpn-client.service значи само дека, ако двете задачи се стартуваат, оваа чека да се стартува другата. Тоа не го влече VPN и не чека VPN да заврши со поврзувањето.

Директивите за барање, како Wants= и Requires=, се грижат за активирањето и се разликуваат по тоа што се случува кога зависноста не успее: едната продолжува, другата запира. Ниту една не знае што значи поврзан тунел. VPN процесот може да биде активен без доделена адреса, или со доделена адреса и без рута до партнерот, и двете состојби ја задоволуваат зависноста. Ако на апликацијата ѝ треба адресата да постои, моделирајте го тој услов експлицитно наместо да го сметате стартувањето на процесот за доказ за подготвеност.

Проверете што единицата навистина декларира со systemctl cat и systemctl show -p After -p Wants -p Requires. Drop-in од три различни директориуми може да додадат директиви што никогаш не сте ги напишале, а systemd ја чита само ефективната единица.

Што network-online.target не прави

Единица подредена по network-online.target чека менаџерот на мрежата да ја прогласи мрежата за употреблива, што е точка на синхронизација при подигнување, а не постојан услов. Таа не кажува ништо за тоа дали одреден тунел е кренат и нема да се активира повторно кога VPN ќе се поврзе повторно попладне. Да се третира како монитор за повторно поврзување е најчестото погрешно читање на таа цел.

Проектот systemd директно ја документира таа разлика, а практичната последица е дека сѐ што бара тунелска адреса мора самото да ја поседува зависноста. Единица што чека network-online и потоа врзува тунелска адреса е точна само кога тунелот случајно ќе се крене прв, а тоа е случајност, а не дизајн.

Тестирајте го животниот циклус што навистина го избравте

Тестирајте чисто подигнување, барање откако ќе се појави адресата и однесувањето откако VPN ќе падне и ќе се врати. Тие три случаи го одвојуваат слушачот што работи од услугата што работи.

systemd-analyze verify myapp.socket
systemctl cat myapp.socket
ss -ltn "sport = :8443"

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

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