systemd VPN кызматын токтотот: Type= параметрин кардарга шайкештештириңиз
Жүктөө учурунда иштеп баштаган VPN бирдиги Type= кардардын өмүрүнө туура келбегенде активдүү эмес болуп калат. Түрүн шайкештештириңиз, ээликти оңдоп, кызматты туннелден кийин реттеңиз.
Бирдиктер туура көрүнүшү мүмкүн, systemctl start ийгилик жөнүндө билдириши мүмкүн, ал эми он секунддан кийин кызмат активдүү эмес бойдон калат. Же иштетүү чеги токтотконго чейин ар жарым мүнөт сайын кайра жүктөлөт. Бул жүрүм-турумдардын бири да тармактын бузулушу эмес: бирдик кардар иш жүзүндө жасаган ишке туура келбеген процесс өмүрүн сүрөттөйт. Кардар fork жасап чыгып кетиши мүмкүн, же сессияны конфигурациялап дароо чыгып кетиши мүмкүн.
Ийгиликтүү иштетүүдөн кийин бир нече секунддан кийин бирдик эмнеге активдүү эмес болот
systemd абалды өзү иштеткен процесстен чыгарат, ошондуктан Type= ошол процесс жөнүндөгү ырастоо, документтештирүү эмес. Type=simple менен бирдик буйрук иштеп жатканда активдүү деп эсептелет жана ал кайтканда активдүү эмес болот. Ошондуктан байланышты жардамчыга өткөрүп чыгып кеткен кардар кыйроо сыяктуу көрүнөт, туннель иштеп турса да. Андан кийин журнал иштетүү жана токтотуу үлгүсүн көрсөтөт, ал бузулган бинар катары окулат.
Тармак конфигурациясына тийүүдөн мурун бирдиктин түрүн кардардын жүрүм-туруму менен катар окуңуз.
Кардарга туура келген түрдү тандаңыз
Эки үлгү жеткирүүчүлөрдүн CLIлеринин көбүн кампыйт: сессияны конфигурациялап чыгып кетүүчү буйрук жана кайтуудан мурун жардамчыны fork кылган буйрук. Ар бирине өзүнчө бирдик формасы керек.
[Service]
Type=oneshot
RemainAfterExit=true
ExecStart=/usr/bin/protonvpn-cli connect -f
ExecStop=/usr/bin/protonvpn-cli disconnectoneshot RemainAfterExit=true менен бирге буйрук кайткандан кийин да бирдикти активдүү кармайт, бул конфигурацияла жана чык үлгүсүнө туура келет, ал эми токтотуу буйругу кызматка таза жабылуу берет. Fork кылган кардар ошол эле форманы сактайт, бирок systemd баланы ээрчиши үчүн Type=forking керек. Restart=on-failure, RestartSec=30 жана чектелген StartLimitBurst коюңуз, жеткирүүчүнүн үзгүлтүгү катаны көмө турган кайра жүктөө циклинен айланбашы үчүн.
Көзөмөлдөнгөн кардардын демонго айланышына эч качан жол бербеңиз
systemdден тышкары көзөмөлчүлөр да ошол эле дубалга урунат. Демонго айланган кардарды иштеткен runit скрипти дароо көзөмөлчүгө кайтат, ал кайтууну кыйроо деп окуп, дагы бир көчүрмөнү иштетет. Ар бир көзөмөлчү алдыңкы пландагы процесске ээ болууну күтөт, sshd -D алдыда калганы сыяктуу. Көзөмөлдөнгөн буйруктардан демон желегин алып салыңыз жана фондук ишти көзөмөлчүгө калтырыңыз. Туннель пайда боло электе кайткан каптоочу скрипттер да ушундай башаламандыкты жаратат.
Өзүн өзү ажыраткан процесс аны көзөмөлдөшү керек болгон бардык нерсеге көрүнбөйт.
Сессия бүтөт жана туннелди өзү менен алып кетет
Иш тактасынын сессиясы өзү иштеткен кардарга ээлик кылат. Кирүүнү бүтүрсөңүз, сессия шинасы жоголот жана туннелди алып кетет, бул акыркы терезе жабылганда графикалык кардардын байланышы эмнеге тез-тез үзүлөрүн түшүндүрөт. Серверлер өзү көтөрүлгөн системалык бирдикти же NetworkManager профилин колдонушу керек. Колдонуучу бирдиги туннель кирүү менен бүтүшү керек болгондо гана маанилүү, ошондуктан аны графикалык сессиянын максатына байлап, муну сүрөттөмөсүндө белгилеңиз.
Кызматтын колдонуучусу ошол эле көйгөйдүн экинчи жарымы. rootко таандык жана режими 0600 болгон ачкычты башка эсеп менен иштеген бирдик окуй албайт, sudo сиздин кабыгыңызда эмнеге жеткен болбосун.
systemctl cat openvpn-server@work
sudo chown -R openvpn:network /etc/openvpn/server
sudo find /etc/openvpn -type f -perm /077 -lsДарек пайда болгондон кийин көз карандыларды реттеңиз
Демон али түзүлө элек туннель дарегине байланганда, ал Cannot assign requested address менен чыгат. Оңдоо кайталоо цикли эмес, ачык реттөө.
[Unit]
After=network.target [email protected]
Requires=sys-devices-virtual-net-wg0.deviceAfter= иштерди реттейт, ал эми түзмөк бирдигиндеги Requires= көз карандыны интерфейстин бар экендигине байлайт, бул тармак максатын гана күтүүдөн күчтүү. Түзөтүүдөн кийин менеджерди кайра жүктөп, көз каранды кызматты кайра иштетиңиз, анан тартип иштеди деп болжолдоонун ордуна анын журналын окуңуз. Кардардын чыгышын журналга StandardOutput=journal же лог параметри менен жөнөтүңүз, анткени эч ким ачпаган файлга жазган көзөмөлдөнгөн кардар эч качан иштеп баштабаган кардарга так окшош.
Анан бир жолу кайра жүктөп, туннель түзмөгү пайда болгондон кийин бирдиктин активдүү экендигин тастыктаңыз. systemctl start менен гана текшерилген оңдоо оңдошу керек болгон жүктөө тартибин сынаган жок.