OpenVPN active (exited) гэж харуулж байна уу? Таны эхлүүлсэн инстансыг ол
active (exited) нь туннель биш, RemainAfterExit-ийн бариулж буй /bin/true-ийн нэг удаагийн ажил юм. Инстансыг ол, түүний заасан файлыг уншиж, дараа нь түүний журналыг унш.
Та туннелийг шалгаж, systemctl status openvpn ажиллуулахад Main PIDгүй, процессын жагсаалт хоосон active (exited) гарна. Үйлчилгээ эхэлсэн ч үхсэн гэсэн унших нь байгалийн юм, тиймээс та unit-ийг нээж, /bin/true-ийг олж, багц эвдэрсэн гэж дүгнэнэ. Debian багцад энэ төлөв нь зохион бүтээсэн ёсоор ажиллаж буй wrapper бөгөөд туннель нь түүний эхлүүлдэг instance unit-ийн аль нэгэнд амьдардаг. Нийт unit нь аль инстанс үүнийг бүтээснийг хэзээ ч хэлэхгүй.
Энэ unit дээр active (exited) үнэндээ юу гэсэн үг вэ
Багцлагдсан unit нь нэг удаагийн ажил: түүний ExecStart нь /bin/true бөгөөд дууссан unit-ийг active (exited) гэж мэдээлэгдэх байдлаар бариулж байдаг нь RemainAfterExit=yes юм. Тэр зааврыг авбал мөн адил амжилттай /bin/true ажил inactive (dead)-д дуусах бөгөөд энэ нь хүмүүсийн хүлээж, эсрэг чиглэлд буруу уншдаг яг тэр төлөв юм. Команд нь зөвхөн орлуулагч бөгөөд unit нь бусад unit-ийн хийж буй ажлын талаар мэдээлдэг. Энэ зохион байгуулалтад юу ч эвдэрээгүй бөгөөд /bin/true-ийг солих нь туннелийг биш, багцлалтын гэрээг өөрчилдөг.
Wrapper нь даалгавар шилжүүлдэг. Багцын тохиргоо эсвэл түүний systemd үүсгэгчээс нийлүүлсэн instance unit-үүдийг эхлүүлдэг тул хоосон процессын жагсаалт туннелийн талаар юу ч батлахгүй. Ямар ч инстанс сонгогдоогүй ч wrapper амжилттай болж, юу ч эхлүүлэхгүй. Төлөв нь wrapper ажилласан эсэхийг хариулна, туннель байгаа эсэхийг биш.
status-ын гаралтын гурван мөрийг унш, хаалт доторх үгийг биш. Loaded нь systemd-ийн уншсан unit файлыг нэрлэнэ, Active нь сүүлийн амжилттай ажиллагааны цагийн тэмдгийг агуулна, Main PID байхгүй нь дууссан нэг удаагийн ажилд тохирно. Тэр гурван мөр нь энэ wrapper-ийг эхэлснээс хойш нэг секундын дараа унасан үйлчилгээнээс ялгах арга ч юм.
status-ыг дахин уншихаас өмнө unit-үүдийг жагсаа
Юу ажиллаж байгааг асуухаас өмнө systemd-ээс юу байгааг асуу. Ямар ч инстанс үүсээгүй байхад загвар суулгагдсан байж болох бөгөөд зөвхөн үүсгэсэн unit л туннель агуулна. Ачаалсан багцаас эхэл:
systemctl list-units 'openvpn*'
Тэр жагсаалт нь systemd энэ мөчид ачаалсан зүйл бөгөөд туннелийн бүртгэлд хамгийн ойр зүйл юм. Суулгасан unit файлууд өөр асуултад хариулдаг бөгөөд юу ч үүсээгүй үед ч тэр жагсаалт загвар харуулсаар байна:
systemctl list-unit-files 'openvpn*'
Хоёр жагсаалтыг хамт унш, учир нь хоёр дахь дахь загвар, эхнийх дэх инстанс нь хоёр өөр хариулт юм. Байгаа загвар, ажиллаж буй инстанс нь нэг баримт биш бөгөөд зөвхөн хоёр дахь нь туннель гэсэн үг. Багцын зохион байгуулалт нь түгээлт, OpenVPN хувилбараас хамаарч өөр байна. Хуучин openvpn@ загвар, тусдаа client ба server хос, түгээлтийн wrapper нь өөрсдийн багцад хууль ёсны байж болно.
Олсон зааварт биш, өөрийн машинд тохируул. Бусдын гаралт дахь инстансын нэр office байж болох бол таных home эсвэл work байна. Дамждаг нь арга, мөр биш.
Инстансын нэрээр түүний уншдаг файл хүртэл яв
Upstream client загварт unit-ийн ажлын хавтас нь /etc/openvpn/client бөгөөд түүний команд тэндээс %i.conf авдаг тул openvpn-client@office нь /etc/openvpn/client/office.conf-ийг уншдаг. Жишээнд итгэхийн оронд суулгасан unit дээр тэр зураглалыг баталгаажуул, учир нь таны загвар хуучин эсвэл түгээлтийн дахин бичсэн байж болно:
systemctl cat [email protected]
Тэр гаралтын доод хэсэгт гарч буй drop-in-үүдийг унш, учир нь .d/-ийн доорх файл ExecStart, ажлын хавтас эсвэл тохиргооны замыг өөрчилж болно. office.ovpn гэж татсан профайл нь инстансын нээдэг файл биш. Энэ зөрүү нь та хэзээ ч засаагүй замыг алдаа нэрлэх нийтлэг шалтгаан юм.
Профайл доторх харьцангуй замууд нь дараагийн урхи. ca, cert, key лавлагааг харьцангуй үлдээж үндсэн файлыг зөөх нь алга болсон файлын алдааг өөр алга болсон файлын алдаагаар солино. Хоёр дахь нь байгаа гэдэгт та итгэлтэй байсан файлыг заадаг тул профайлын хавтас нь файлын нэрнээс илүү чухал.
Үүнийг эхлүүл, дараа нь тэр инстансын журналыг унш
Саяхан шалгасан инстансаа эхлүүл, учир нь нийт unit-ийн лог туннелийн алдааг агуулахгүй. Дараа нь энэ ачааллын журналыг уншиж, тэр дарааллаар тохиргооны алдаа, файлд хандах алдаа, холболтын алдаа хай, учир нь тус бүр эхлэлийн өөр үе шатанд бүтэлгүйтдэг.
sudo systemctl start [email protected]
journalctl -u [email protected] -b
Эхлүүлэх ба идэвхжүүлэх нь тусдаа шийдвэр: start unit-ийг одоо ажиллуулна, enable дараагийн ачааллыг зохицуулна, enable --now хоёуланг нь нэг алхамаар хийнэ. daemon-reload unit-ийн тодорхойлолтыг дахин уншиж, ажиллаж буй процессыг дахин эхлүүлэхгүй, зассан профайлыг хэрэглэхгүй. Профайлыг өөрчилсний дараа инстансыг дахин эхлүүл, учир нь файлыг дахин уншдаг нь тэр.
Нэг туннельд хоёр дахь менежер бүү тавь
NetworkManager болон OpenVPN 3 сессийн менежерүүд өөрсдийн холболтын төлөвтэй бөгөөд тэдний нэгийн хажууд systemd инстанс байх нь нэг туннельд хоёр эзэн тавьдаг. Шинж тэмдэг нь туннель өргөгдөж, хэдэн секундын дараа солигдох, эсвэл зогссон хэвээр үлдэхээс татгалзах юм. Түгээлт тань ширээний компьютерт зориулж баримтжуулсан менежерийг сонгож, сервер дээр systemd-ийг санаатайгаар ашигла.
Инстанс эхлүүлэхийн өмнө байгаа эзэн байгаа эсэхийг шалга. Ширээний апплет холболтыг харуулах үед таны эхлүүлсэн инстанс түүнийг гүйцээхийн оронд өрсөлддөг. Хоёуланг нь ажиллуулж, дараалал хадгалагдана гэж найдахын оронд ашигладаггүй менежерээ идэвхгүй болго. Тэр зөрчил нь туннель тогтоогдсоны дараа та хэзээ ч эхлүүлээгүй процесс түүнийг эвддэг журналуудыг ч тайлбарлана.
Анхны асуултад инстансын нэр, түүний уншсан файл, бүтэлгүйтсэн журналын мөрөөр хариул. OpenVPN-ийн systemd интеграцийн тухай тэмдэглэл нь загварын зохион байгуулалт болон инстансын нэр шийдэгддэг файлын зураглалыг тайлбарладаг.