Само една кука за спиење нема да го врати VPN-от

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

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

Скрипта што излегува со нула не ви кажала ништо за тоа дали тунелот се вратил.

Куката се извршува, и што потоа?

#!/bin/sh
case "$1" in
  pre)
    vpn-client disconnect
    ;;
  post)
    vpn-client connect
    ;;
esac

Секој настан ја повикува куката двапати, пред преминот и по него, предавајќи ѝ ја фазата и името на настанот. Таа работи како root со минимална околина, затоа се потребни апсолутни патеки и не треба да се очекува променлива од десктоп сесија. Тоа што двете повикувања се враќаат брзо кажува само дека скриптата се извршила. Дали профилот се подигнал потоа е одделно набљудување и бара свој доказ во дневникот.

Третирајте го аргументот за фазата како дел од дизајнот. Обидот за повторно поврзување во фазата pre се случува додека машината е пред да изгуби сето, и не може да успее.

Root, минимална околина, погрешен корисник

Ако клиентот го чува токенот за најава по корисник, извршувањето на куката како root ја остава без ништо да претстави. Проверете ја состојбата под идентитетот што куката навистина го користи, а не тој што сте го тестирале од десктоп терминал. Некои градби по исклучувањето оставаат и демон што го држи интерфејсот, па повторното поврзување паѓа во застарена состојба, а чистењето на процесот прво го враќа по цена на нечисто исклучување. Ниту едно од двете однесувања не е видливо ако тестирате само среќниот пат.

Пишете ја куката со апсолутни патеки, држете ја во сопственост на root и извршлива, и запишете што направила. Без тој дневник следната истрага почнува од нула.

Автоматското поврзување не е патот на VPN

NetworkManager нуди два механизми за активирање: знаменце за автоматско поврзување на профилот и секундарни врски што почнуваат кога се активира примарен профил. Домашните типови уреди го спроведуваат првото; VPN додатоците историски го спроведувале само второто, па означувањето автоматско поврзување на OpenVPN профил може воопшто да нема ефект. Проверете ги двете својства, потоа прикачете го VPN-от како секундарен на Wi-Fi или Ethernet профилот.

[Unit]
PartOf=NetworkManager.service
Requires=NetworkManager-wait-online.service
After=NetworkManager-wait-online.service

WireGuard интерфејсот управуван од systemd единица бара таа дополнителна датотека наместо кука, подреден откако мрежата е онлајн.

Почекајте ја мрежата, со горна граница

timer=1
while ! ping -c1 -n -w1 203.0.113.1 >/dev/null; do
  sleep 1; timer=$((timer+1))
  [ $timer -ge 300 ] && exit 0
done
nmcli connection up "work-vpn"

При будење тунелот може да биде побарано додека Wi-Fi се уште се поврзува повторно, што го прави секое фиксно спиење погодување. Почекајте достапна адреса, потоа подигнете го профилот, и ограничете го чекањето за куката да не може неограничено да го држи патот на будењето отворен. Претпочитајте го името на профилот пред нумерички индекс, и ако правилниот профил се разликува по мрежа, нека здравиот тунел однапред го запише својот избор во датотека.

Чувајте се и од бури од рестартирање, со броење обиди и запирање. Надзорник што реагира на секоја неуспешна проверка претвора еден прекин во јамка.

Суспендирајте еднаш, потоа прочитајте го дневникот за сопствениот излез на куката. Тоа е единствениот тест што го докажува редоследот.

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