systemd sustabdo VPN paslaugą: suderinkite Type= su klientu

Paleidimo metu veikiantis VPN vienetas tampa neaktyvus, kai Type= neatitinka kliento gyvavimo trukmės. Suderinkite tipą, sutvarkykite nuosavybę ir sudėliokite paslaugą po tunelio.

Vienetai gali atrodyti teisingai, systemctl start gali pranešti apie sėkmę, o po dešimties sekundžių paslauga stovi neaktyvi. Arba ji perkraunama kas pusę minutės, kol paleidimo riba jos nesustabdo. Nė vienas elgesys nėra tinklo gedimas: vienetas aprašo proceso gyvavimo trukmę, kuri neatitinka to, ką klientas iš tikrųjų daro. Klientas gali atsileisti ir išeiti arba sukonfigūruoti sesiją ir išeiti iš karto.

Kodėl vienetas tampa neaktyvus per kelias sekundes po sėkmingo paleidimo

systemd būseną nustato iš proceso, kurį pats paleido, todėl Type= yra teiginys apie tą procesą, o ne dokumentacija. Su Type=simple vienetas laikomas aktyviu, kol komanda veikia, ir tampa neaktyvus, kai ji grįžta. Todėl klientas, kuris perduoda ryšį pagalbininkui ir išeina, atrodo kaip avarija, net kai tunelis veikia. Tada žurnalas rodo paleidimo ir sustabdymo modelį, kuris skaitomas kaip sugedęs dvejetainis failas.

Perskaitykite vieneto tipą šalia kliento elgesio, prieš liesdami tinklo konfigūraciją.

Pasirinkite tipą, kuris atitinka klientą

Du modeliai apima daugumą tiekėjų CLI: komanda, kuri sukonfigūruoja sesiją ir išeina, ir komanda, kuri prieš grįždama atsileidžia pagalbininką. Kiekvienam reikia kitokios vieneto formos.

[Service]
Type=oneshot
RemainAfterExit=true
ExecStart=/usr/bin/protonvpn-cli connect -f
ExecStop=/usr/bin/protonvpn-cli disconnect

oneshot su RemainAfterExit=true palieka vienetą aktyvų po komandos grįžimo, kas atitinka konfigūruok-ir-išeik modelį, o sustabdymo komanda suteikia paslaugai švarų išjungimą. Atsileidžiantis klientas išlaiko tą pačią formą, bet jam reikia Type=forking, kad systemd sektų vaiką. Nustatykite Restart=on-failure, RestartSec=30 ir baigtinį StartLimitBurst, kad tiekėjo triktis nevirstų perkrovimų ciklu, užkasančiu klaidą.

Niekada neleiskite prižiūrimam klientui tapti demonu

Prižiūrėtojai už systemd ribų atsimuša į tą pačią sieną. runit paleidimo scenarijus, paleidžiantis demonizuotą klientą, iškart grįžta prižiūrėtojui, o jis tą grįžimą perskaito kaip avariją ir paleidžia dar vieną kopiją. Kiekvienas prižiūrėtojas tikisi valdyti priekinį procesą, kaip sshd -D lieka priekyje. Nuimkite demono vėliavą prižiūrimoms komandoms ir palikite fono darbą prižiūrėtojui. Apvalkalų scenarijai, kurie grįžta anksčiau, nei atsiranda tunelis, sukelia tą pačią painiavą.

Procesas, kuris atsiskiria nuo savęs, yra nematomas viskam, kas turėjo jį stebėti.

Sesija baigiasi ir nusineša tunelį

Darbalaukio sesija valdo klientą, kurį paleidžia. Baikite prisijungimą ir sesijos magistralė išnyksta, nusinešdama tunelį, o tai paaiškina, kodėl grafinio kliento ryšys dažnai nutrūksta uždarant paskutinį langą. Serveriai turėtų naudoti sistemos vienetą arba NetworkManager profilį, kuris pakyla pats. Naudotojo vienetas prasmingas tik tada, kai tunelis turi baigtis kartu su prisijungimu, todėl susiekite jį su grafinės sesijos tikslu ir tai nurodykite aprašyme.

Paslaugos naudotojas yra kita tos pačios problemos pusė. root valdomas raktas su 0600 režimu yra neperskaitomas vienetui, veikiančiam su kita paskyra, kad ir ką sudo būtų pasiekęs jūsų apvalkale.

systemctl cat openvpn-server@work
sudo chown -R openvpn:network /etc/openvpn/server
sudo find /etc/openvpn -type f -perm /077 -ls

Sudėliokite priklausomus po to, kai adresas atsiranda

Kai demonas prisiriša prie tunelio adreso, kuris dar nesukurtas, jis išeina su Cannot assign requested address. Taisymas yra aiški tvarka, o ne kartojimų ciklas.

[Unit]
After=network.target [email protected]
Requires=sys-devices-virtual-net-wg0.device

After= sudėlioja užduotis, o Requires= įrenginio vienete susieja priklausomą su sąsajos egzistavimu, kas yra stipriau nei laukti vien tinklo tikslo. Po redagavimo iš naujo įkelkite tvarkyklę ir perkraukite priklausomą paslaugą, tada perskaitykite jos žurnalą, o ne manykite, kad tvarka suveikė. Siųskite kliento išvestį į žurnalą su StandardOutput=journal arba žurnalo parinktimi, nes prižiūrimas klientas, rašantis į failą, kurio niekas neatidaro, atrodo identiškai kaip tas, kuris niekada nebuvo paleistas.

Tada vieną kartą paleiskite iš naujo ir patvirtinkite, kad vienetas aktyvus po to, kai pasirodo tunelio įrenginys. Taisymas, patikrintas tik su systemctl start, neišbandė paleidimo tvarkos, kurią turėjo sutvarkyti.

Susiję straipsniai