Ваш 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, а не тунель. Запішыце, які ўладальнік запускае службу і дзе жыве сакрэт, бо наступнаму чалавеку, які перазагрузіць гэтую машыну, спатрэбяцца абодва факты.