Ваш VPN ради само након пријаве због привеска кључева

Наредба ради кад сте пријављени, па је ставите у скрипту за покретање и одете кући. Следећег јутра рачунар је на мрежи, а тунел није. Мит је да радни позив значи радна услуга. У пракси је разлика обично једна од две ствари: профил припада вашој корисничкој сесији, а не систему, или тајну откључава нешто што постоји тек након што се пријавите. Обоје савршено ради у ручном тесту и закаже тачно у тренутку кад нико не гледа.

Зашто пријава то омогућава

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

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

Одлучите који власник покреће тунел

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

systemctl list-unit-files 'openvpn*'
systemctl list-unit-files 'wg-quick*'
nmcli connection show --active
systemctl enable --now wg-quick@wg0

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

Ставите тајну тамо где је услуга може прочитати

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

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

Тестирајте догађај који се стварно дешава

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

systemctl is-enabled wg-quick@wg0
journalctl -u wg-quick@wg0 -b --no-pager
systemctl status systemd-networkd-wait-online --no-pager

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

Проверите руте и DNS, не само сучеље

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

ip -4 route show
resolvectl status
ping -c 3 10.61.0.1
curl -sS --max-time 5 https://internal.example/ -o /dev/null -w '%{http_code}\n'

Ако адреса ради, а име не, преостали проблем је DNS политика, а не тунел. Запишите који власник покреће услугу и где живи тајна, јер следећој особи која поново покрене овај рачунар требаће обе чињенице.