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

Поврзани статии