OpenVPN орон нутгийн машин дээр хувийн түлхүүрийн нууц үгийг асуудаг тул ажиллаж буй нэвтрэх файл түүнд хэзээ ч хариулдаггүй. Үйлчилгээнд бичих терминал байхгүй бөгөөд эхлэл нь эсвэл дүүжлэгдэх, эсвэл шалтгааныг биш, оролтыг нэрлэсэн журналын бичлэгтэйгээр бүтэлгүйтдэг. Энд хоёр нууц байгаа бөгөөд unit-ийг дахин эхлүүлэхийн өмнө тус бүр өөрийн уншигдах эх сурвалжтай байх ёстой. Доорх зам тэдгээрийг тусгаарлаж, дараа нь файл бүрийг үнэхээр нээж буй таних тэмдгийг шалгана.

Хоёр хүсэлтийг ялгана уу

Түлхүүрийн нууц үг орон нутгийн хувийн түлхүүрийг тайлж, бүртгэлийн мэдээлэл сессийг серверт баталгаажуулна. Тэд өөр өөр газраас ирж, өөр өөр үед бүтэлгүйтэж, өөр өөр мессеж өгдөг. Тэдгээрийг хольсон тохиолдолд хүмүүс нууц үг сэргээх ажил хайдаг боловч бүртгэл огт оролцоогүй байсан. Аль нууц дутуу байгааг харуулах цорын ганц найдвартай дохио нь үг хэллэг тул аливаа тохиргоог өөрчлөхийн өмнө хүсэлтийн текстийг уншина уу.

Community OpenVPN 2.x-д askpass эхний мөрөнд түлхүүрийн нууц үг агуулсан файлыг зааж, auth-user-pass нэг мөрөнд хэрэглэгчийн нэр, дараагийн мөрөнд нууц үг агуулсан файлыг заана. Аль ч файл нөгөө тохиргоог хангаж чадахгүй. Ажлын талын апп эсвэл NetworkManager профайл хоёуланг нь өөрийн нууц санд хадгалж болох бөгөөд командын мөрийн клиент түүнийг хэзээ ч уншдаггүй тул аливаа зам бичихийн өмнө аль клиентийг тохируулж байгаагаа тэмдэглээрэй.

Хоёр тохиргоог уншигдах файлууд руу чиглүүлнэ үү

Хоёр оролт шаардлагатай профайл эцэстээ гурван файлын лавлагаатай болно: шифрлэгдсэн түлхүүр, түүнийг нээх нууц үг, нэвтрэх хос. Тэдгээрийг CA болон таних тэмдгийн шалгалтыг хөндөхгүйгээр нэмнэ үү, учир нь тэдгээр нь сервер хэн болохыг шийддэг бөгөөд энэ асуудлын хэсэг биш. Хэрэв байршуулалт бүртгэлийн мэдээллийг огт ашиглахгүй бол auth-user-pass нэмэх нь хэн ч өгч чадахгүй оролт үүсгэдэг.

key /etc/openvpn/client/office.key
askpass /etc/openvpn/client/office-key.pass
auth-user-pass /etc/openvpn/client/office-login.auth

Аргументгүй тохиргоо замтай тохиргооноос өөрөөр ажилладаг бөгөөд үйлчилгээнд энэ ялгаа чухал. Аргументгүй askpass консолыг уншсаар байдаг бөгөөд зөвхөн хэрэглэгчийн нэртэй auth-user-pass файл нууц үгийн хүсэлтийг хүлээлгэсээр үлддэг. Клиент демон болсны дараа терминалаас оролт асуух боломжгүй тул ингэж тохируулсан үйлчилгээ босохгүй.

Үнэмлэхүй замууд ажлын лавлахын асуултыг арилгадаг ч хандалт өгдөггүй. Дараа нь эзэмшил, горим, нэвтрэлт ирдэг бөгөөд гурвыг процесс ажиллаж буй бүртгэлтэй харьцуулан шалгадаг.

Профайлаас өмнө unit-ийн тохиргоог уншина уу

Аль тохиргоог ачаалахыг unit шийддэг, таны засварлаж байсан файл биш. Түүний командын мөр болон бүх drop-in-ийг уншаад, ажлын лавлахаар дамжин үнэхээр ашиглагдаж буй профайлд хүрнэ үү. Өөр .ovpn файлд нэмсэн нууц үгийн лавлагаа энэ хувилбарт юу ч өөрчлөхгүй.

Гурван зөвхөн унших команд үүний ихэнхэд хариулна. Эхнийх нь unit болон бүх drop-in-ийг, хоёр дахь нь процессыг хязгаарлах таних тэмдэг болон sandbox тохиргоог, гурав дахь нь сүүлийн эхлэл үнэхээр юуны талаар гомдоллосныг хэвлэнэ. Хост дээр байгаа хувилбарын нэрийг ашиглана уу:

systemctl cat [email protected]
systemctl show [email protected] -p User -p Group -p WorkingDirectory -p ProtectHome
journalctl -u [email protected] -b

ProtectHome болон профайлын өөрийн user, group, chroot тохиргоонд анхаарна уу. Гэрийн лавлахын доорх файл таны shell-д уншигдах боловч гэрийн лавлахуудыг нуухад үйлчилгээний дотор харагдахгүй болно. systemd-ийн эхлүүлдэг бүртгэл үргэлж түлхүүрийг эцэст нь нээдэг бүртгэл байдаггүй.

Ажиллах үеийн таних тэмдэг хоёр файлыг нээж чадахыг батална уу

Горимыг унших нь хангалтгүй, учир нь зам дээрх лавлах бүр ижил таних тэмдгээр нэвтрэх боломжтой байх ёстой. Замыг бүрэлдэхүүн хэсэг тус бүрээр туулж, дараа нь процессын ашигладаг бүртгэлээр нээхийг туршина уу. root-ийн эзэмшилд байгаа 600 горимтой файл процесс root хэвээр байх үед л ажилладаг бөгөөд олон профайлын хийдэг эрх мэдэл бууруулалтын дараа энэ нь үнэн биш. Хоёр команд нэвтрэлт болон нээлтийг хамарна:

namei -l /etc/openvpn/client/office-key.pass
sudo -u openvpn test -r /etc/openvpn/client/office-key.pass && echo readable

Эхний команд бүрэлдэхүүн хэсэг бүрийн горимыг хэвлэж, бүртгэл нэвтэрч чадахгүй газарт бүтэлгүйтнэ; хоёр дахь нь цорын ганц чухал асуултад хариулна, өөрөөр хэлбэл ажиллах үеийн таних тэмдэг файлыг уншихаар нээж чадах эсэх. Аль нь ч файлын агуулгыг хэвлэхгүй бөгөөд файл нууц үг агуулж байхад энэ нь гол зүйл. Нэвтрэх файлд мөн туршилтыг давтана уу, учир нь хоёулаа ихэвчлэн өөр эзэмшилтэй хадгалагддаг.

Хэрэв процесс chroot эсвэл хязгаарлагдмал namespace ашигладаг бол мөн адил туршилтыг тэр харагдацын дотроос ажиллуулна уу, эс бөгөөс хариулт буруу файлын системийг дүрсэлнэ. Нуугдмал гэрийн лавлахын доор хадгалсан нууц үг нь unit-ээс гадна давж, дотор нь бүтэлгүйтдэг туршилтын ердийн жишээ юм.

Эхний эхлэлийг, дараа нь дахин холболтыг шалгана уу

Хувилбарыг нэг удаа эхлүүлж, сүүлийн биш эхний бүтэлгүйтлийг уншина уу. Дутуу оролтын файл, түлхүүрийн тайлалтын бүтэлгүйтэл, серверийн талаас AUTH_FAILED нь гурван өөр үйл явдал бөгөөд гурван өөр засвартай. Зөвшөөрлийн анхааруулгыг засах нь түлхүүр нээгдсэн эсэхийг юу ч батлахгүй.

Журналын мөр гурвын алийг нь байгааг хэлнэ. Засвар нь аль оролт бүтэлгүйтсэнээс гарна:

What the journal showsWhich input failedWhere to look
A path that cannot be openedThe file the profile namesAskpass or login path, and the unit's working directory
A key decryption errorThe key passphraseFirst line of the askpass file, and read access for the runtime identity
AUTH_FAILED from the serverThe account credentialsLogin file contents, and whether the account is still valid

Дараа нь танд үнэхээр хэрэгтэй амьдралын мөчлөгийг туршина уу: ачаалах үеийн эхлэл болон дэмжигдсэн аливаа дахин холболт, зөвхөн shell-ээс гараар эхлүүлэх нь биш. auth-nocache үед оролтууд эхний хэрэглэлийн дараа хаягддаг тул дараагийн дахин холболтод уншигдах эх сурвалж хэрэгтэй хэвээр. Ажлын талд нэвтрэх үед нээгддэг түлхүүрийн цагираг хэн нэгэн нэвтрэхээс өмнө эхэлсэн үйлчилгээнд боломжгүй бөгөөд гараар хийсэн туршилт давж, дахин ачаалалт бүтэлгүйтдэг нийтлэг шалтгаан энэ юм. Хэрэв эхний эхлэл амжилттай болж, дараагийн дахин холболт бүтэлгүйтвэл зөвшөөрлийг дахин өөрчлөхийн өмнө дахин холболтын үйл явдлын журналыг уншина уу.

Нууц үгийг түлхүүрийн дэргэд хадгалах нь шифрлэлтийн өгөх ашгийг бууруулдаг тул тэр файл болон түүний нөөц хуулбарыг хязгаарлана уу. Түлхүүрийн нууц үгийг хасахыг дутуу оролтын засвар биш, тусдаа итгэмжлэлийн шийдвэр гэж үзнэ үү. Хүний зөвшөөрөл эсвэл интерактив MFA-аас хамааралтай байршуулалтад өөрийн дэмжигдсэн агент эсвэл удирдлагын интеграц хэрэгтэй; байнга хадгалсан нэг удаагийн код нь тэнцүү орлуулалт биш.

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