Kāpēc jūsu OpenVPN klients paliek izslēgts pēc viena taimauta

Pirmdienas rīts: tunelis, kas pacēlās piektdien, ir pazudis, saskarne joprojām ir sarakstā, un žurnālā nekas nav rakstīts, ka kāds to būtu pamanījis. Resurss ir tiešsaistē, panelis ir zaļš, un viss, ko tas nedēļas nogalē nosūtīja, izgāja pa fizisko saskarni. Šeit trūkst divu neatkarīgu lēmumu: viens par to, vai klienta process pārdzīvo īslaicīgu kļūmi, un otrs par to, vai kaut kas virs tā atkal palaiž procesu pēc tā iziešanas. Izlabojot tikai vienu, otra plaisa paliek atvērta.

Sāciet ar to, ko vienība patiešām izdarīja, nevis ar to, ko apgalvo uzraudzība. systemctl status openvpn-client@office un journalctl -u openvpn-client@office -n 50 parāda iziešanas iemeslu un pēdējo rindu, ko klients ierakstīja pirms aiziešanas.

Process izgāja, pirms kāds to pamanīja

Klients, kas pazūd bez kļūdas, parasti ir izgājis tīši. Šo uzvedību nosaka profils, nevis pakalpojumu pārvaldnieks: ping-exit beidz procesu, tiklīdz pretējā puse pārstāj atbildēt, bet ping-restart patur procesu un atkal pieslēdzas tā iekšienē. Sesijas ierobežojumi un neaktivitātes taimeri no ārpuses rada tādu pašu ainu: bez tuneļa un bez trauksmes.

Abas ping direktīvas nevar būt kopā vienā profilā, tāpēc izvēlieties vienu un pierakstiet izvēli. Apskatiet arī serveri, jo tā paša ping-exit aizver sesiju neatkarīgi no tā, ko klients pieprasīja, un tikai servera žurnāls fiksē, kas pieņēma šo lēmumu.

Izvēle starp ping-exit un ping-restart

Izvēlieties ping-restart klēpjdatoram vai attālam objektam, kam jāizdziedē pašam, un saglabājiet ping-exit gadījumiem, kad mirušam tunelim jāaptur process, lai kaut kas cits varētu uz to reaģēt. Skaitļi ir mazāk svarīgi par saistību: ping 10 ar ping-restart 60 nozīmē desmit sekundes klusuma pirms pārbaudes un sešdesmit pirms restartēšanas, kas ir agresīvi mobilajā saitē ar zudumiem un saprātīgi vadu saitē. Pierakstiet iemeslu blakus rindai, citādi nākamais lasītājs pieņems, ka noklusējuma vērtības bija apzinātas.

Pēc tam pārliecinieties, ka tiešām izgāja process. Vienība, kas ziņo par aktivitāti, kamēr tunelis ir miris, ir cita kļūme, kas aplūkota tālāk.

Uzraudzība, kas tiešām restartē vienību

systemd resursā mazākā noturīgā izmaiņa ir viens drop-in fails: Restart=on-failure un RestartSec=10 failā /etc/systemd/system/[email protected]/restart.conf. Drop-in tiek lasīts tikai tad, kad systemd pārlādē savas definīcijas, tāpēc pēc tam palaidiet systemctl daemon-reload. Pārbaudiet ar systemctl show -p Restart -p ExecMainStatus openvpn-client@office, nevis pieņemiet, ka vērtība ir nonākusi. Faila nosaukumā esošajai instancei jābūt profilam, ko vienība tiešām ielādē, tāpēc fails, kas rakstīts office, neko nedara openvpn-client@home.

on-failure ignorē vienu gadījumu: tīru iziešanu ar statusu nulle. Daži demontāžas ceļi beidzas tā, tāpēc lasiet ierakstīto statusu, nevis uzticieties rokasgrāmatas lapas formulējumam. Ja jūsu klients padodas ar nulli, jums vajag Restart=always, un cena ir tā, ka patiešām salauzts profils atgriežas atkal un atkal, līdz iedarbojas palaišanas ātruma ierobežojums un žurnāls piepildās.

Restart=always iedarbojas arī pēc tīša apturējuma. Apkopei izmantojiet systemctl stop, un maskējiet vienību, ja tai jāpaliek izslēgtai, kamēr strādājat.

Noķeriet noplūdi, kamēr tunelis ir izslēgts

Uzraudzība atgriež tuneli; tā neliedz trafikam iziet, kamēr tuneļa nav. persist-tun saglabā ierīci un tās maršrutus starp atkārtotiem savienojumiem, kas ir ērti un atver logu. Ierīce izdzīvo, maršruti joprojām ir vērsti uz to, un paketes izplūst neaizsargātas un neziņotas. Tas ir politikas lēmums, nevis neitrāla noklusējuma vērtība.

Kad resursam vispār nedrīkst izlaist neaizsargātas paketes, to var garantēt tikai ugunsmūris. Izejas noteikums, kas atļauj tuneļa saskarni un VPN servera adresi un nomet visu pārējo, darbojas arī pēc klienta nāves, un klienta paša konfigurācijā nekas nevar filtrēt trafiku, ko klients nepārvada.

Pārbaudiet to, tīši apturot klientu. Palaidiet systemctl stop openvpn-client@office, tad curl -m 5 https://example.com, kam vajadzētu neizdoties, nevis izdoties pa fizisko saiti. Panākums nozīmē, ka ugunsmūra noteikuma trūkst vai tas ir pārāk atļaujošs.

Pieslēdzieties no jauna, pārliecinieties, ka tunelis atkal pārvada trafiku, un tikai tad pievienojiet pārbaudi uzraudzībai. ip addr aptauja no cron tun ierīcei ir uzraudzība, kas neizdodas visbiežāk, jo ar persist-tun ierīce pārdzīvo sesiju un pārbaude ziņo par veselību, kamēr nekas netiek pārvadāts.