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 disconnect

oneshot нь 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.device

After= ажлуудыг эрэмбэлдэг бол төхөөрөмжийн нэгж дээрх Requires= хамааралтыг интерфейсийн оршин тогтнохтой холбодог, энэ нь зөвхөн сүлжээний зорилтыг хүлээхээс илүү хүчтэй. Засварын дараа менежерийг дахин ачаалж, хамааралтай үйлчилгээг дахин эхлүүл, дараа нь эрэмбэ ажилласан гэж таамаглахын оронд түүний журналыг унш. Клиентийн гаралтыг журнал руу StandardOutput=journal эсвэл логын сонголтоор илгээ, учир нь хэн ч нээдэггүй файлд бичдэг хяналтад байгаа клиент хэзээ ч эхлээгүй клиенттэй яг адил харагддаг.

Дараа нь нэг удаа дахин ачаалж, туннелийн төхөөрөмж гарч ирсний дараа нэгж идэвхтэй байгааг батал. Зөвхөн systemctl start-аар шалгасан засвар нь засах ёстой байсан ачааллын дарааллыг туршаагүй.

Холбоотой нийтлэлүүд