Зошто OpenVPN умира по будењето на лаптопот?

Спиењето може да ја убие сесијата на OpenVPN и да го остави tun0. Тестирајте го тунелот, потоа рестартирајте ја единицата од systemd спиечки хук, а не уредот.

Ставете ја машината во спиење, разбудете ја, па пред да допрете каква било конфигурација проверете три работи по овој ред: дали tun0 се уште постои, дали рутата до внатрешна адреса се уште го избира и дали серверот се уште го наведува овој peer. Уред што го преживува спиењето додека рутата покажува на друго место е остаток, не тунел. Кога рутата е точна, а сообраќајот сепак умира, дефектот е над тунелот и рестартирањето на клиентот нема да го смени. Автоматизирањето на рестартирање има смисла само откако рачен тест ќе покаже кој од тие три случаи го имате.

ip -br address show tun0
ip route get 10.20.0.10
journalctl -u openvpn-client@office -b --no-pager | tail -30

Репродуцирајте го будењето пред да го автоматизирате

Спиењето почесто ја завршува шифрираната сесија отколку што го отстранува уредот. UDP текот што го одржуваше тунелот жив запира, серверот може да го отфрли peer, а клиентот или го забележува и се поврзува повторно или задржува интерфејс без ништо зад него. Самата проверка на интерфејсот докажува малку, затоа што застарениот уред изгледа исто како оној што работи додека пакетите не мора да поминат низ него. Извршете го пребарувањето на рутата плус едно вистинско барање низ тунелот, потоа прочитајте го дневникот околу моментот на будењето.

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

Каде всушност живее systemd спиечкиот хук

Многу стари водичи покажуваат на /etc/pm/sleep.d, директориум што го поседува pm-utils и што спиење засновано на systemd никогаш не го консултира. systemd чита хукови од /usr/lib/systemd/system-sleep/ и /etc/systemd/system-sleep/, прво ја предава фазата, а потоа операцијата, па pre и post се единствените вредности на кои хукот се разгранува. Чувајте ја локалната копија под /etc наместо да уредувате спакувана датотека, и запомнете дека скриптата работи како root во средината на транзицијата, затоа мора брзо да се врати.

#!/bin/sh
case "$1" in
  post)
    systemctl --no-block try-restart [email protected]
    ;;
esac
exit 0

try-restart допира единица само кога таа веќе е активна, па тунелот што намерно сте го исклучиле останува исклучен низ будењето. --no-block го спречува хукот да чека додека клиентот преговара, што е важно кога мрежата се уште не е крената. Заедно двете знаменца значат хук што тивко пропаѓа наместо да ја задржи целата секвенца на будење. Кога единицата е веќе запрена, воопшто ништо не се случува, што е токму резултатот што го сакате таму.

Вратете ја услугата, оставете tun0 на мира

Спуштањето на tun0 рачно го остава демонот да надгледува интерфејс што повеќе не го поседува, а следната промена на состојбата создава збунувачки грешки. Целете ја услугата или нејзиниот профил за поврзување, а не интерфејсот; прво проверете го точното име на единицата, бидејќи дистрибуциските пакети, OpenVPN 3 и NetworkManager избираат различни. NetworkManager профилот се враќа кога таа врска се рециклира, па systemd единицата таму не е целта. Каков и да е механизмот, тоа треба да биде истото дејство што сте го провериле рачно.

Рестартирањето повторно ги инсталира рутите што клиентот ги турна при поврзувањето. Повеќето будења го сакаат тоа. Машина во која сте додале свои патеки не, па проверете ги тие повторно наместо да претпоставите дека опоравувањето ги вратило, и запишете ги таму каде следното будење може да ги најде.

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

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

Разрешувањето имиња е посебна трка, затоа што мрежниот стек на работната површина може да го врати DNS откако тунелот е веќе кренат. Тестирајте ги пребарувањата посебно со resolvectl query internal.example наместо да ги изведувате од работна рута. Тунел што правилно рутира и ништо не разрешува е DNS проблем, не проблем на хукот.

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

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