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

கண்காணிப்பு கூறுவதிலிருந்து அல்ல, யூனிட் உண்மையில் என்ன செய்தது என்பதிலிருந்து தொடங்குங்கள். systemctl status openvpn-client@office மற்றும் journalctl -u openvpn-client@office -n 50 வெளியேறியதற்கான காரணத்தையும், கிளையண்ட் செல்வதற்கு முன் எழுதிய கடைசி வரியையும் காட்டுகின்றன.

யாரும் கவனிக்கும் முன் செயல்முறை வெளியேறியது

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

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

ping-exit மற்றும் ping-restart இடையே தேர்வு

தானாகவே குணமாக வேண்டிய மடிக்கணினி அல்லது தொலைத் தளத்திற்கு ping-restart தேர்ந்தெடுங்கள், இறந்த சுரங்கப்பாதை செயல்முறையை நிறுத்தி வேறு ஏதாவது அதற்கு பதிலளிக்க வேண்டிய சந்தர்ப்பங்களுக்கு ping-exit வைத்திருங்கள். எண்களை விட உறவு முக்கியம்: ping 10 உடன் ping-restart 60 என்பது சோதனைக்கு முன் பத்து வினாடி அமைதி மற்றும் மறுதொடக்கத்திற்கு முன் அறுபது, இது இழப்புள்ள மொபைல் இணைப்பில் ஆக்கிரமிப்பானது, கம்பி இணைப்பில் நியாயமானது. காரணத்தை வரிக்கு அருகில் எழுதுங்கள், இல்லையெனில் அடுத்த வாசகர் இயல்புநிலை மதிப்புகள் வேண்டுமென்றே என்று கருதுவார்.

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

யூனிட்டை உண்மையில் மறுதொடக்கம் செய்யும் மேற்பார்வை

systemd புரவலனில் மிகச் சிறிய நீடித்த மாற்றம் ஒரு drop-in கோப்பு: Restart=on-failure மற்றும் RestartSec=10 /etc/systemd/system/[email protected]/restart.conf இல் உள்ளன. systemd தனது சொந்த வரையறைகளை மீண்டும் ஏற்றும்போது மட்டுமே drop-in படிக்கப்படுகிறது, எனவே அதன் பிறகு systemctl daemon-reload இயக்குங்கள். மதிப்பு வந்துவிட்டது என்று கருதாமல் systemctl show -p Restart -p ExecMainStatus openvpn-client@office மூலம் சரிபாருங்கள். கோப்புப் பெயரில் உள்ள நிகழ்வு யூனிட் உண்மையில் ஏற்றும் சுயவிவரமாக இருக்க வேண்டும், எனவே office க்காக எழுதப்பட்ட கோப்பு openvpn-client@home க்கு எதுவும் செய்யாது.

on-failure ஒரு நிலையை புறக்கணிக்கிறது: நிலை பூஜ்ஜியமாக இருக்கும் தூய வெளியேற்றம். சில அகற்றல் பாதைகள் அப்படியே முடிகின்றன, எனவே கையேடு பக்கத்தின் வார்த்தைகளை நம்பாமல் பதிவு செய்யப்பட்ட நிலையைப் படியுங்கள். உங்கள் கிளையண்ட் பூஜ்ஜியத்துடன் விட்டுவிட்டால், உங்களுக்கு Restart=always தேவை, அதன் விலை என்னவென்றால் உண்மையில் உடைந்த சுயவிவரம் தொடக்க விகித வரம்பு செயல்பட்டு ஜர்னல் நிரம்பும் வரை மீண்டும் மீண்டும் திரும்புகிறது.

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

சுரங்கப்பாதை கீழே இருக்கும்போது கசிவைப் பிடியுங்கள்

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

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

கிளையண்டை வேண்டுமென்றே நிறுத்தி இதைச் சோதியுங்கள். systemctl stop openvpn-client@office இயக்குங்கள், பின்னர் curl -m 5 https://example.com, அது இயற்பியல் இணைப்பில் வெற்றிபெறாமல் தோல்வியடைய வேண்டும். வெற்றி என்பது தீச்சுவர் விதி இல்லை அல்லது மிகவும் அனுமதிக்கும் விதியாக உள்ளது என்பதாகும்.

மீண்டும் இணையுங்கள், சுரங்கப்பாதை மீண்டும் போக்குவரத்தை சுமப்பதை உறுதிப்படுத்துங்கள், பின்னரே சரிபார்ப்பை கண்காணிப்பில் சேர்க்கவும். cron இலிருந்து ip addr ஐ tun சாதனத்திற்காகக் கேட்பது அதிகம் தோல்வியடையும் மேற்பார்வை, ஏனெனில் persist-tun உடன் சாதனம் அமர்வை விட நீண்ட காலம் வாழ்கிறது, எதுவும் சுமக்கப்படாதபோதும் சோதனை ஆரோக்கியம் எனத் தெரிவிக்கிறது.

தொடர்புடைய கட்டுரைகள்