Pse një njësi VPN niset para rrjetit dhe pastaj vdes

Nisni makinën, identifikohuni dhe zbuloni se tuneli u ngrit dhe vdiq disa sekonda më vonë. Profili ishte në rregull, certifikata ishte në rregull, dhe gjurma e vetme që mbeti është regjistri i atij nisjeje. Ajo që zakonisht ndodhi është një garë: njësia nisi përpara se makina të kishte një adresë, dhe rendi që deklaroi nuk do të thoshte atë që duket. Gjithçka më poshtë ka të bëjë me vërtetimin e asaj gare nga provat dhe mbylljen e saj si duhet.

Objektivi është pikë takimi, jo menaxher

network-online.target nuk e ka idenë se çfarë është një rrjet. Është një pikë koordinimi që mbledh atë shërbim që duhet ta vonojë nisjen derisa lidhja të jetë e përdorshme, dhe ia delegon përkufizimin atij menaxheri të rrjetit që zotëron makinën. Në shumicën e desktopëve dhe serverëve kjo do të thotë një shërbim pritjeje që ofrohet nga NetworkManager ose nga systemd-networkd. Nëse nuk aktivizoni asnjërin, objektivi nuk ka për çfarë të presë, kështu që përfundon në momentin që diçka e tërheq brenda, dhe kjo mund të ndodhë shumë përpara se DHCP të përgjigjet. Rreshti i rendit në njësinë tuaj ishte i sinqertë dhe gjithsesi i padobishëm.

Prandaj pyetja e parë nuk është çfarë deklaron njësia juaj. Është nëse diçka në këtë makinë po e bën vërtet pritjen.

Lexoni nisjen e fundit, jo skedarin e njësisë

Skedarët e njësive përshkruajnë qëllimin, dhe regjistri përshkruan atë që ndodhi. Kërkoni vetëm atë nisje, me vulat kohore monotonike që çdo mesazh të ulet në një orë të vetme. Pastaj gjeni dy rreshta: momentin kur njësia e tunelit filloi të nisej, dhe momentin kur u shfaq adresa ose përfundoi shërbimi i pritjes. Renditni ata dy numra dhe gara ose konfirmohet ose përjashtohet.

Pamja e varësive e vërteton këtë. Nëse një zinxhir kritik për njësinë e tunelit nuk përmban shërbim pritjeje, asgjë në atë rrugë nuk e vonoi nisjen, dhe objektivi nuk e bëri punën që supozuat. Dy pamje, një përfundim.

systemctl list-units --type=service --state=running | grep wait-online
journalctl -b -o short-monotonic -u openvpn-client@office

Shtoni pritjen, pastaj provën e re

Përdorni një drop-in në vend që të redaktoni një njësi të paketuar, që një përditësim pakete të mos e hedhë ndryshimin në heshtje. Dy direktiva kanë rëndësi: njësia duhet të renditet pas objektivit, dhe duhet ta tërheqë objektivin në të njëjtin transaksion. Vetëm rendi nuk e thërret objektivin; dëshira e bën këtë.

Njësia e paketuar e klientit OpenVPN tashmë i mban të dyja. Njësitë e shkruara me dorë zakonisht mbajnë njërën ose asnjë, gjë që ia vlen të kontrollohet përpara se të shtoni ndonjë gjë.

[Service]
Restart=on-failure
RestartSec=15

Pse një gjumë fiks është kurth

Një gjumë në ExecStartPre duket si një rregullim rendi dhe sillet si një vonesë me hapa shtesë. Ai e ngadalëson çdo nisje, përfshirë ato që ishin të shëndetshme, dhe humbet gjithsesi kur lidhja zgjat më shumë se numri që zgjodhët.

Më keq, ai fsheh nëse shërbimi i pritjes funksionon, kështu që dështimi i radhës shfaqet si një problem krejt i ri dhe jo si i njëjti me kohë tjetër. Një vonesë e shkurtër rinisjeje është instrumenti më i mirë: nuk kushton asgjë në një nisje të shëndetshme dhe e kthen një garë të humbur në një provë tjetër. Mbajeni intervalin modest dhe lëreni njësinë të ketë sukses. Nëse riniset përgjithmonë, profili është i prishur dhe asnjë sasi provash nuk e ndryshon atë, prandaj lexoni regjistrin në vend që të ngrini intervalin.

Kur rendi është i saktë dhe emrat ende dështojnë

Një njësi aktive me një rrugë tuneli do të thotë që rendi e bëri punën e vet dhe defekti i mbetur është një shtresë më lart. Forma e zakonshme është një rregullim resolveri që skripti up i tunelit e zbaton përpara se lidhja ose resolveri të ishte gati ta mbante. Krahasoni gjendjen e resolverit gjatë dështimit me gjendjen pas një rinisjeje të njësisë së tunelit.

Nëse rinisja i rregullon kërkimet, ju keni një defekt të rendit të nisjes dhe jo një server DNS të gabuar, dhe të dy kërkojnë rregullime të ndryshme. Pastaj vërtetoni gjithçka me një nisje të ftohtë në vend të një rinisjeje shërbimi, sepse rinisja punon kundër një rrjeti që është tashmë lart dhe do të fshehë pikërisht defektin që po ndiqni. Përsëriteni me lidhjen qëllimisht të ngadaltë, dhe trajtojeni një njësi që punon vetëm kur rrjeti është i shpejtë si ende të prishur.