மடிக்கணினி எழுந்த பிறகு OpenVPN ஏன் இறக்கிறது?

இயந்திரத்தை உறக்க நிலைக்கு அனுப்பி, மீண்டும் எழுப்பி, பின்னர் எந்தவொரு உள்ளமைவையும் தொடுவதற்கு முன் இந்த வரிசையில் மூன்று விஷயங்களைச் சரிபார்க்கவும்: tun0 இன்னும் உள்ளதா, உள் முகவரிக்கான பாதை இன்னும் அதைத் தேர்ந்தெடுக்கிறதா, சேவையகம் இன்னும் இந்த peer-ஐ பட்டியலிடுகிறதா. பாதை வேறெங்கோ காட்டும்போது உறக்கத்திலிருந்து தப்பிக்கும் சாதனம் ஒரு எச்சம், சுரங்கப்பாதை அல்ல. பாதை சரியாக இருந்தும் போக்குவரத்து இறந்தால், குறைபாடு சுரங்கப்பாதைக்கு மேலே உள்ளது, கிளையண்டை மீண்டும் தொடங்குவதால் அது மாறாது. கைமுறைச் சோதனை இந்த மூன்றில் எது உங்களிடம் உள்ளது என்று காட்டிய பிறகே மீண்டும் தொடங்குவதை தானியங்குபடுத்துவது அர்த்தமுள்ளது.

ip -br address show tun0
ip route get 10.20.0.10
journalctl -u openvpn-client@office -b --no-pager | tail -30

தானியங்குபடுத்தும் முன் எழுந்திருப்பை மீண்டும் உருவாக்குங்கள்

உறக்கம் சாதனத்தை அகற்றுவதை விட அதிகமுறை மறையாக்கப்பட்ட அமர்வை முடிக்கிறது. சுரங்கப்பாதையை உயிர்ப்புடன் வைத்திருந்த UDP ஓட்டம் நிற்கிறது, சேவையகம் peer-ஐ விட்டுவிடலாம், கிளையண்ட் அதைக் கவனித்து மீண்டும் இணைகிறது அல்லது பின்னால் எதுவும் இல்லாத இடைமுகத்தை வைத்திருக்கிறது. இடைமுகச் சரிபார்ப்பு மட்டும் சிறிதளவே நிரூபிக்கிறது, ஏனெனில் பழைய சாதனம் வேலை செய்யும் சாதனம் போலவே தெரிகிறது தொகுப்புகள் அதன் வழியாகச் செல்ல வேண்டியிருக்கும் வரை. பாதைத் தேடலை இயக்கி, சுரங்கப்பாதை வழியாக ஒரு உண்மையான கோரிக்கையைச் செய்து, பின்னர் எழுந்திருக்கும் தருணத்தைச் சுற்றியுள்ள பதிவைப் படியுங்கள்.

கிளையண்ட் தானாகத் திரும்பினால், hook நம்பகத்தன்மைக்குப் பதிலாக கூடுதல் சிரமத்தைச் சேர்க்கிறது. அது ஒருபோதும் மீளவில்லை என்றால், தானியங்குபடுத்தலே நேர்மையான தீர்வு.

systemd தூக்க hook உண்மையில் எங்கே வாழ்கிறது

பல பழைய வழிகாட்டிகள் /etc/pm/sleep.d-ஐச் சுட்டுகின்றன, இது pm-utils-ஐச் சொந்தமாகக் கொண்ட கோப்பகம், systemd அடிப்படையிலான உறக்கம் அதை ஒருபோதும் கலந்தாலோசிப்பதில்லை. systemd /usr/lib/systemd/system-sleep/ மற்றும் /etc/systemd/system-sleep/-இல் இருந்து hook-களைப் படித்து, முதலில் கட்டத்தையும் பின்னர் செயல்பாட்டையும் அனுப்புகிறது, எனவே pre மற்றும் post மட்டுமே hook கிளைபிரியும் மதிப்புகள். தொகுக்கப்பட்ட கோப்பைத் திருத்துவதற்குப் பதிலாக உள்ளூர் நகலை /etc-இன் கீழ் வைத்திருங்கள், மேலும் ஸ்கிரிப்ட் மாற்றத்தின் நடுவில் root ஆக இயங்குகிறது என்பதை நினைவில் கொள்ளுங்கள், எனவே அது விரைவாகத் திரும்ப வேண்டும்.

#!/bin/sh
case "$1" in
  post)
    systemctl --no-block try-restart [email protected]
    ;;
esac
exit 0

try-restart ஏற்கனவே செயலில் இருக்கும் போது மட்டுமே யூனிட்டைத் தொடுகிறது, எனவே நீங்கள் வேண்டுமென்றே மூடிய சுரங்கப்பாதை எழுந்திருப்பு முழுவதும் மூடியே இருக்கும். --no-block கிளையண்ட் பேச்சுவார்த்தை நடத்தும்போது hook காத்திருப்பதைத் தடுக்கிறது, இது நெட்வொர்க் இன்னும் எழாதபோது முக்கியம். இரண்டு கொடிகளும் சேர்ந்து முழு எழுந்திருப்பு வரிசையையும் பிடித்து வைப்பதற்குப் பதிலாக அமைதியாகத் தோல்வியடையும் hook-ஐக் குறிக்கின்றன. யூனிட் ஏற்கனவே நிறுத்தப்பட்டிருந்தால் எதுவும் நடக்காது, அது அங்கே நீங்கள் விரும்பும் முடிவே.

சேவையை மீட்டெடுத்து, tun0-ஐ தனியாக விடுங்கள்

tun0-ஐ கைமுறையாகக் கீழிறக்குவது, டீமனை இனி அதற்குச் சொந்தமில்லாத இடைமுகத்தை மேற்பார்வையிட வைக்கிறது, அடுத்த நிலை மாற்றம் குழப்பமான பிழைகளை உருவாக்குகிறது. இடைமுகத்திற்குப் பதிலாக சேவை அல்லது அதன் இணைப்புச் சுயவிவரத்தை இலக்காகக் கொள்ளுங்கள்; முதலில் யூனிட்டின் சரியான பெயரைச் சரிபார்க்கவும், ஏனெனில் விநியோகத் தொகுப்புகள், OpenVPN 3 மற்றும் NetworkManager அனைத்தும் வெவ்வேறானவற்றைத் தேர்ந்தெடுக்கின்றன. NetworkManager சுயவிவரம் அந்த இணைப்பு மறுசுழற்சி செய்யப்படும்போது திரும்பி வருகிறது, எனவே systemd யூனிட் அங்கே இலக்கு அல்ல. எந்த வழிமுறையாக இருந்தாலும், அது நீங்கள் கைமுறையாகச் சரிபார்த்த அதே செயலாக இருக்க வேண்டும்.

மீண்டும் தொடங்குவது கிளையண்ட் இணைந்தபோது தள்ளிய பாதைகளை மீண்டும் நிறுவுகிறது. பெரும்பாலான எழுந்திருப்புகளுக்கு அது தேவை. நீங்கள் சொந்தப் பாதைகளைச் சேர்த்த இயந்திரத்திற்கு தேவையில்லை, எனவே மீட்பு அவற்றைத் திரும்பவைத்தது என்று கருதுவதற்குப் பதிலாக அவற்றை மீண்டும் சரிபார்க்கவும், அடுத்த எழுந்திருப்பு அவற்றைக் கண்டறியக்கூடிய இடத்தில் எழுதி வையுங்கள்.

உங்களால் கட்டுப்படுத்த முடியாத நேரத்தைக் கையாளுங்கள்

கம்பியில்லா இணைப்பு மற்றும் DHCP பெரும்பாலும் hook இயங்கிய பிறகே முடிகின்றன, எனவே சேவையகத்திற்கான பாதை இன்னும் இல்லாதபோது மீண்டும் தொடங்குவது தோல்வியடையலாம். அந்த முகவரிக்கு சிறிது காத்திருந்து, மீண்டும் ஒருமுறை முயற்சித்து, முடிவைப் பதிவு செய்யுங்கள்.

பெயர் தீர்வு ஒரு தனி பந்தயம், ஏனெனில் டெஸ்க்டாப் நெட்வொர்க் ஸ்டாக் சுரங்கப்பாதை ஏற்கனவே மேலே வந்த பிறகு DNS-ஐ மீட்டெடுக்கலாம். வேலை செய்யும் பாதையிலிருந்து ஊகிப்பதற்குப் பதிலாக resolvectl query internal.example உடன் தேடல்களைத் தனித்தனியாகச் சோதிக்கவும். சரியாக வழிநடத்தி எதையும் தீர்க்காத சுரங்கப்பாதை DNS பிரச்சினை, hook பிரச்சினை அல்ல.

பதிவில் கட்டம், யூனிட்டின் பெயர் மற்றும் முடிவை எழுதி hook-இன் முடிவைத் தெரியும்படி வைத்திருங்கள். எந்த எழுந்திருப்புச் சோதனையை இயக்கினீர்கள் என்று இயந்திரக் குறிப்புகளில் எழுதுங்கள், அதனால் செயல்படும் மீட்பை அதிர்ஷ்டமான மீட்பிலிருந்து வேறுபடுத்தலாம். சேவையைத் திரும்பக் கொண்டுவரும் மிகக் குறைந்த இடையூறான செயலைத் தேர்ந்தெடுத்து, தானாக மீளும் கிளையண்டை அதைச் செய்ய விடுங்கள். முழுமையான மறுதொடக்கம் நடந்துகொண்டிருக்கும் அமர்வுகளை வீழ்த்துகிறது, இது நாளொன்றுக்கு பலமுறை எழும் மடிக்கணினியில் உண்மையான செலவு.