OpenVPN кызматы жеке ачкычтын сырсөзүн сураганда токтойт: кантип оңдоого болот
Кызматта терминал жок, ошондуктан шифрленген ачкычка askpass жана окулуучу файл керек. Ачкычтын сырсөзүн серверге кирүүдөн бөлүп, unit-ти текшериңиз.
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] -bProtectHome жана профилдин өзүнүн 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 shows | Which input failed | Where to look |
|---|---|---|
| A path that cannot be opened | The file the profile names | Askpass or login path, and the unit's working directory |
| A key decryption error | The key passphrase | First line of the askpass file, and read access for the runtime identity |
AUTH_FAILED from the server | The account credentials | Login file contents, and whether the account is still valid |
Анан сизге чындыгында керек болгон жашоо циклин сынаңыз: жүктөө учурунда баштоо жана колдоого алынган ар кандай кайра туташуу, shellиңизден кол менен баштоо гана эмес. auth-nocache болгондо киргизүүлөр биринчи колдонуудан кийин ташталат, ошондуктан кийинки кайра туташууга дагы эле окулуучу булак керек. Иш тактасына кирүүдө ачылуучу ачкыч шакеги бирөө киргенге чейин башталган кызматка жеткиликсиз, жана кол менен сыноонун өтүп, кайра жүктөөнүн ийгиликсиз болушунун кадимки себеби ушул. Эгер биринчи баштоо ийгиликтүү болуп, кийинки кайра туташуу ийгиликсиз болсо, уруксаттарды кайра өзгөртүүдөн мурун кайра туташуу окуясы үчүн журналды окуңуз.
Сырсөздү ачкычтын жанында сактоо шифрлөөнүн берерин азайтат, ошондуктан ошол файлды жана анын камдык көчүрмөлөрүн чектеңиз. Ачкычтын сырсөзүн алып салууну жетишпеген киргизүүнү оңдоо эмес, өзүнчө эсептик маалымат чечими катары караңыз. Адамдын уруксатына же интерактивдүү MFAга көз каранды жайылтууга анын колдоого алынган агенти же башкаруу интеграциясы керек; туруктуу сакталган бир жолку код барабар алмаштыруу эмес.