OpenVPN auth-user-pass: файл, stdin эсвэл асуулт уу? Хэрхэн сонгох вэ

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

Үүнийг шийдэх гурван нөхцөл

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

Итгэмжлэлийн файл нь процесс хяналтгүй эхэлж, нууц нь хяналттай зөвшөөрлийн багцын дор дискэн дээр үлдэж чадах үед зөв хариулт юм. Нууцыг огт бичихийг хориглосон үед - зөвхөн сангийн бодлого, богино хугацааны токен - клиентийн нээж чадах урсгал хэрэгтэй бөгөөд энэ нь практикт процессын орлуулалт эсвэл файлын дескрипторт бичдэг туслах гэсэн үг. Удирдлагын интерфейс дөрөв дэх тохиолдлыг хамарна: туннелийн амьдралын мөчлөгийг аль хэдийн удирддаг, сокетоор асуултад хариулж чаддаг контроллер.

• Консол дээр хүн, автоматжуулалтгүй: интерактив асуулт.
• Хяналтгүй эхлэл, нууцыг хадгалж болно: 0600 горимтой итгэмжлэлийн файл.
• Хяналтгүй эхлэл, нууцыг хадгалахыг хориглоно: процессын орлуулалт эсвэл нууцын агент бичдэг fd.
• Клиентийг өөр процесс эзэмшдэг: удирдлагын интерфейс.

Хоёр хариулт тохирох үед нууцыг argv болон shell-ийн түүхээс гадуур байлгахыг сонго. Программын аргумент болгон өгсөн нууц үгийг процессын жагсаалтаар дамжуулан аливаа локал хэрэглэгч уншиж чадна, энэ илчлэлтийг буцаах хэцүү.

Оролтын зам бүр бодитоор юу хийдэг вэ

--auth-user-pass ганцаараа консол дээр хэрэглэгчийн нэр, нууц үг асуудаг. Файлын нэр өгвөл клиент эхний мөрийг хэрэглэгчийн нэр, хоёр дахь мөрийг нууц үг гэж авна; ямар ч зүйл хашилт, тайлбар эсвэл түлхүүр-утгын синтаксийг дэмждэггүй. Энэ бол бүхэл формат, тиймээс INI файл хүлээж засварладаг хэн бүхэн үүнийг эвддэг. Оруулсан <auth-user-pass> блок профайл дотор мөнөөх хоёр мөрийг хадгалж, профайлыг өөрөө нууц болгож, хувийн түлхүүртэй ижил зохицуулалтын ангилалд оруулдаг.

Үлдсэн хоёр зам нь урсгал ба сокет. OpenVPN-д зөвхөн уншиж болох файлын дескриптор хэрэгтэй тул процессын орлуулалт, хоолойгоор дэмжигдсэн /dev/fd бичлэг эсвэл бодитоор FIFO болох файлын нэрийг хүлээж авна. Удирдлагын интерфейс мөн чанараараа өөр: клиент утгуудыг өөрөө уншихын оронд хянагч процессоос асуудаг. Энэ ялгаа дахин холбогдох үед чухал: итгэмжлэлийн файл, нууцын туслах дахин бичиж чадах FIFO, удирдлагын интерфейс хүнгүйгээр дахин нийлүүлж чадна; процессын орлуулалт чадахгүй, учир нь дескриптор эхний уншилтад зарцуулагддаг.

Файл яг хоёр мөр байх ёстой

Эвдэрсэн итгэмжлэлийн файлуудын ихэнхийг хоёр гэмтлийн горим хамардаг. Windows засварлагч CRLF төгсгөл үлдээдэг, вагоны буцалт нууц үгийн хэсэг болж, сервер дэлгэц дээр зөв харагдах утгыг татгалздаг. Хоосон хоёр дахь мөр - нууц үг байх ёстой газарт хоосон мөр - клиентийг хоосон нууц үгтэй үлдээж, дэлгэц дээрх утга зөв харагдсан ч сервер татгалздаг. Нууц үгийн дараах нэмэлт шинэ мөр хор хөнөөлгүй. Файлыг засварлагчаас биш, shell-ээс бичиж, байтуудыг шалгаарай:

install -m 600 /dev/null /etc/openvpn/client.creds
printf '%s\n%s\n' "$VPN_USER" "$VPN_PASS" > /etc/openvpn/client.creds
od -c /etc/openvpn/client.creds | head -3

Зам нь агуулгын адил чухал. Харьцангуй зам нь процессын ажлын лавлахтай харьцуулан шийдэгддэг бөгөөд үйлчилгээний хувьд энэ нь таны туршсан лавлах байх нь ховор. Үнэмлэхүй зам ашиглаж, файлыг клиентийг ажиллуулдаг бүртгэлийн өмч болгож, бүлэг болон бусад нь уншиж чадахгүйн тулд 0600 горимыг хадгал. OpenVPN 2.6 гарын авлага зааврын хүлээн зөвшөөрөгдсөн хэлбэрүүдийг жагсаасан; гурав дахь хэлбэрийг зохиохоос өмнө үүнийг шалгаарай.

Серверийг буруутгахаас өмнө файлыг туршиж үзээрэй. openvpn --config client.ovpn --auth-user-pass /etc/openvpn/client.creds --verb 4 ажиллуулахад файл нээгдсэн эсэх, дараа нь итгэмжлэлүүд хүлээн авсан эсэхийг хэвлэдэг бөгөөд энэ нь дараагийн аль давхаргыг өөрчлөхийг хэлж өгдөг.

Урсгал, stdin болон тэдгээрийн үүсгэдэг алдаа

Нууц үгийг хоолойд хийх нь ихэнх хүмүүсийн хамгийн түрүүнд туршдаг зүйл бөгөөд хамгийн их гэнэтийн зүйлтэй зам юм. Процессын орлуулалт ажилладаг, учир нь клиентэд зөвхөн уншиж болох дескриптор хэрэгтэй: openvpn --config client.ovpn --verb 3 --auth-user-pass <(printf '%s\n%s\n' "$VPN_USER" "$VPN_PASS"). /dev/stdin дамжуулах нь клиент асуух мөчид stdin нээлттэй, уншиж болохуйц байх үед л ажилладаг бөгөөд үүнийг аль хэдийн зарцуулсан хоолойд энэ нь үнэн биш.

ERROR: could not read Auth username from stdin хоёр өөр шалтгаантай. Зарим 2.3.x клиент дээр мессеж нь stdin-ийн зохицуулалтын гэмтлээс гарсан бөгөөд дараагийн 2.3 хувилбарууд үүнийг зассан, тиймээс ийм хуучин клиент зөвхөн шинэчлэлтээр сайжирдаг. Одоогийн клиент дээр мөнөөх томьёолол нь клиент консолын оролт хүссэн, stdin терминал байгаагүй гэсэн үг - яг systemd нэгж, cron даалгавар эсвэл -t-гүй эхлүүлсэн контейнерт байдаг нөхцөл байдал.

auth-nocache эвдэрсэн нууц үг мэт харагдах гурав дахь давталт нэмдэг. Хэрэглэсний дараа итгэмжлэлүүдийг санах ойгоос хаядаг тул сүлжээний өөрчлөлтөөс үүдэлтэй дахин холболтод дахин тоглуулах зүйл үлдэхгүй бөгөөд асуулт буцаж ирдэг. Энэ бол зохион бүтээсэн ёсоор ажиллаж буй заавар юм. auth-nocache клиентийн санах ойд хадгалж буй зүйлийг өөрчилдөг, сервер эсвэл таних тэмдгийн нийлүүлэгчийн бүртгэлийн талаар бодож буй зүйлийг биш, тиймээс бүх засвар нь мөнөөх файлыг дахин нийлүүлэх бөгөөд дахин эхлүүлэхэд дахин уншигдана - удирдлагатай холболтын хувьд энэ нийлүүлэлт нь батлагдсан нууцын сангаас ирэх ёстой, скрипт доторх нууц үгээс биш.

Асуултыг өөр процесс эзэмших үеийн удирдлагын интерфейс

Туннелийг аль хэдийн хянаж буй контроллер түүний асуултад ч хариулж чадна. Клиентийг --management 127.0.0.1 7505-тэй эхлүүлж, төлөвийн мөрүүдийг уншиж, >PASSWORD:Need 'Auth' username/password-г анхаарч үзээрэй. Контроллер тусдаа командын мөрүүдэд username "Auth" alice ба дараа нь password "Auth" ...-тэй хариулдаг. 'Auth' токен хүсэлтийн танигчийг давтаж, тохирох ёстой, эс бөгөөс хариултыг үл тоомсорлож, клиент хүлээнэ.

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

Итгэмжлэлийн асуудал мэт харагдах бүтэлгүйтэл

Хэзээ ч дуусахгүй TLS гар барилт, эсвэл VERIFY ERROR: depth=0, error=certificate signature failure нь итгэлцлийн асуудал бөгөөд ямар ч хэрэглэгчийн нэр уншигдахаас өмнө тохиолддог. UDP сонсогч руу чиглэсэн proto tcp клиент мөн тэр газарт бүтэлгүйтдэг: пакетууд баталгаажуулалтын үе шатанд хэзээ ч хүрдэггүй тул нууц үг бүр холбооноос болж буруу харагддаг. Итгэмжлэлийг илгээхээс өмнө гэрчилгээний шалгалтыг асаалттай байлга; танил асуулт нууц үгийг хэн авч байгаа талаар юу ч хэлдэггүй. Итгэмжлэлд хүрэхээс өмнө гэрчилгээний гинжин хэлхээ, нийтлэг нэр, тээврийг шалгаарай.

Профайлыг угсардаг скрипт дэх shell-ийн алдаа нь нөгөө хуурамч ул мөр юм. [ ! -f "$file" ] доторх дутуу зай нь command not found үүсгэж, скрипт эрт зогсож, профайл хэзээ ч дахин бүтээгдэхгүй, клиент өмнөхөөрөө эхэлдэг. Тэр алдаа нь баталгаажуулалтад биш, shell-д хамаарах бөгөөд нууц үгийг хэдэн ч удаа дахин бичсэнээр арилгахгүй.

Энэ урсгал дахь асуулт бүр энэ итгэмжлэл биш. Хувийн түлхүүрийн нууц үг, HTTP проксид нэвтрэх, үйлчилгээний нууц үг нь өөр өөр үе шатанд асуудаг гурван өөр нууц бөгөөд түлхүүрийн нууц үгийг ихэвчлэн auth-user-pass биш, клиент эсвэл агент зохицуулдаг. Хэрэв асуулт TLS сессийг тогтоохоос өмнө гарч ирвэл та буруу асуултад хариулж байгаа бөгөөд бүртгэл шинэчлэх нь тус болохгүй. Буруу асуултыг хассаны дараа үлдсэн шалгалтууд хамгийн эрт давхаргаас эхэлдэг:

• Сүүлийн итгэмжлэлийн мөрийг биш, эхний протоколын алдааг уншаарай: TLS, дараа нь баталгаажуулалт, дараа нь push.
• Файл хоёр мөр, вагоны буцалтгүй, үнэмлэхүй замаар заасан эсэхийг баталгаажуул.
• Профайл болон командын мөр зааврын талаар зөрчилдөхгүй байгааг баталгаажуул.
• "Итгэмжлэл хүлээн авсан" ба "урсгал урсаж байна"-г тусгаарла - чиглүүлэлт болон DNS нь дараагийн давхарга.

Клиент push үе шатанд хүрэхэд итгэмжлэл рүү харахаа зогсоож, серверийн илгээсэн маршрут болон DNS серверүүдийг уншиж эхэл. Энэ бол дараагийн асуудал бөгөөд саяхан зассан нууц үгтэй ямар ч холбоогүй.