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 சேவையகங்களையும் படிக்கத் தொடங்குங்கள். அது அடுத்த சிக்கல், நீங்கள் இப்போது சரிசெய்த கடவுச்சொல்லுடன் அதற்கு எந்தத் தொடர்பும் இல்லை.