Вашият VPN работи само след вход, заради ключодържателя

Командата работи, когато сте влезли, затова я слагате в скрипт за начален старт и отивате вкъщи. На следващата сутрин машината е онлайн, а тунелът — не. Мигът е, че работещо извикване е работеща услуга. На практика разликата обикновено е едно от две неща: профилът принадлежи на потребителската ви сесия, а не на системата, или тайната се отключва от нещо, което съществува само след като влезете. И двете работят безупречно при ръчен тест и се провалят точно в момента, когато никой не гледа.

Защо след влизане работи

Графичният вход стартира шина за сесия и агент на услуга за тайни, и именно там много клиенти, насочени към десктопа, държат паролата на профила или паролата за частния ключ. Активация, която се изпълнява като вашия потребител след вход, може да поиска тайната от този агент и да успее. Същата активация, изпълнена от unit при зареждане, няма сесия, няма шина и няма агент, затова търсенето се проваля или блокира на подкана, която никой не вижда.

Стартирайте същия профил преди и след вход и получавате два различни резултата от една конфигурация. Това е подписът на зависимост от идентификационни данни, а не на счупен тунел, и обяснява защо ръчният тест в терминал доказва по-малко, отколкото изглежда. Тунелът е наред; липсва това, което отключва тайната му.

Решете кой собственик стартира тунела

Има два поддържани модела и смесването им е другият начин това да се провали. NetworkManager може да активира връзка на системно ниво, което е подходящо, когато машината вече централизира мрежата си там. Като алтернатива, отделен unit на systemd стартира VPN директно и сам притежава интерфейса.

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

Не стартирайте двата собственика срещу една конфигурация. Ако NetworkManager управлява интерфейса и unit също го вдига, те ще се борят за маршрути и DNS, а полученото състояние зависи от това кой е приключил последен.

Сложете тайната там, където услугата може да я прочете

Фонова услуга не може да отговори на подкана. Паролите за сертификати, паролите за акаунти и посочените файлове за удостоверяване се нуждаят от такава организация на съхранение, до която unit може да стигне без човек, притежавана от акаунта, който стартира услугата, и нечетима за всички останали.

Изкушаващото бързо решение е да направите файла четим за всички, докато грешката за правата изчезне. Това заменя провал при стартиране срещу дълготрайно излагане на идентификационни данни и е точно онзи вид промяна, към която никой не се връща. Използвайте механизма, на който внедряването вече вярва: ограничен файл с идентификационни данни, нешифрован ключ, защитен с права на файла, или връзка на системно ниво със собствено хранилище за тайни.

Тествайте събитието, което наистина се случва

Ръчното стартиране на услугата след вход не тества почти нищо. Рестартирайте или изключете графичния вход за един цикъл и наблюдавайте unit да се вдигне сам. Това е единственият тест, който едновременно проверява наличността на идентификационни данни, готовността на мрежата и подредбата на unit. Това е и тестът, който възпроизвежда провала, за който потребителят съобщи, каквото ръчното стартиране никога не прави.

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

Подредбата е също толкова важна, колкото идентификационните данни. Unit, който стартира преди конфигурирането на основната връзка нагоре, ще се откаже, а някои дистрибуции се различават по това дали изчакват свързаност. Ако unit съобщи провал при зареждане, но успее при ръчно стартиране тридесет секунди по-късно, сте открили проблем с подредбата, а не с тайната.

Проверявайте маршрутите и 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, а не тунелът. Запишете кой собственик стартира услугата и къде живее тайната, защото следващият човек, който ще рестартира тази машина, ще се нуждае от двата факта.