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

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

செயல்முறையில் தொடங்குங்கள், உள்ளமைவில் அல்ல

ஒரு வழித்தடத்தைத் தொடும் முன் முனையத்தைத் திறந்து இன்னும் என்ன இயங்குகிறது என்று கேளுங்கள். pgrep -a openconnect ஒவ்வொரு நிகழ்வையும் அதன் வாதங்களுடன் பட்டியலிடுகிறது, இது pid கோப்பையும் அதற்கு வழங்கப்பட்ட ஸ்கிரிப்டையும் காட்டுகிறது. நீங்கள் எதிர்பாராத ஒரு செயல்முறை பேய் சுரங்கப்பாதையை எந்தப் பதிவையும் விட வேகமாக விளக்குகிறது.

எதுவும் இயங்கவில்லை என்றால், இணைப்பைப் பாருங்கள். ip link show tun0 இடைமுகம் தப்பிப் பிழைத்ததா என்று சொல்கிறது, மேலும் ip route show dev tun0 இன்னும் அதனுடன் பிணைக்கப்பட்ட வழித்தடங்களைப் பட்டியலிடுகிறது. பின்னர் resolver-ஐ இதன் மூலம் சரிபாருங்கள் resolvectl status. மாற்றும் முன் மூன்று வெளியீடுகளையும் எழுதி வையுங்கள், ஏனெனில் அந்தப் பதிவே பின்னர் பழைய பதிவை புதியதிலிருந்து வேறுபடுத்தும் வழி.

சென்றுவிட்ட இடைமுகம் வழக்கமாக அதன் வழித்தடங்களையும் கொண்டு செல்கிறது. இணைப்புக்குப் பிறகும் தங்கியிருக்கும் வழித்தடங்கள் பொதுவாக செயல்முறை இன்னும் உயிருடன் உள்ளது அல்லது இரண்டாவது கிளையண்ட் சாதனத்தை வைத்திருக்கிறது என்று பொருள்.

மாற்றங்களைத் திரும்பப் பெறுவது உதவி ஸ்கிரிப்டே

openconnect இடைமுகம், வழித்தடங்கள் அல்லது resolver பதிவுகளைத் தானே அகற்றாது. அது வெளிப்புற உதவியாளரை அழைக்கிறது, /etc/vpnc/vpnc-script upstream build இல் மற்றும் /usr/share/vpnc-scripts/vpnc-script Debian மற்றும் Ubuntu தொகுப்புகளில், தேர்ந்தெடுக்கப்படுவது -s ஆல். சுரங்கப்பாதையை உயர்த்தும் அதே ஸ்கிரிப்டே அதை உடைக்கிறது.

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

அந்தப் பாதையை அடையும் சிக்னல் பதிப்புகளுக்கிடையே மாறியது. 7.06 கையேடு SIGTERM-ஐ ஸ்கிரிப்டைத் தவிர்க்கும் உடனடி வெளியேற்றமாகக் கருதுகிறது. தற்போதைய build INT மற்றும் TERM-ஐ அமர்வு வெளியேற்றப்பட்டு உதவியாளர் இயங்கும் தூய நிறுத்தமாக ஆவணப்படுத்துகின்றன. இரண்டு நடத்தைகளில் ஒன்றை ஊகிப்பதற்குப் பதிலாக உங்களிடம் உண்மையில் உள்ள பைனரியின் SIGNALS பகுதியைப் படியுங்கள்.

man openconnect | sed -n '/^SIGNALS/,/^LIMITATIONS/p'

உங்கள் build ஆவணப்படுத்தும் சிக்னலை அனுப்புங்கள்

சிக்னல் தெரிந்த பிறகு செயல்முறையை முறையால் அல்ல, pid ஆல் நிறுத்துங்கள்.

pgrep -a openconnect
sudo kill -INT "$(cat /var/run/openconnect.pid)"

பின்னர் வெளியேற்ற நிலையை நம்புவதற்குப் பதிலாக முதல் பகுதியின் மூன்று சோதனைகளை மீண்டும் செய்யுங்கள். ip link show tun0 தோல்வியடைய வேண்டும், ip route show dev tun0 எதையும் அச்சிடக்கூடாது, மற்றும் resolvectl status இனி VPN இணைப்பைப் பட்டியலிடக்கூடாது.

SIGHUP நிறுத்தும் பொத்தான் அல்ல: அது துண்டிக்கிறது, ஸ்கிரிப்டை இயக்குகிறது, அமர்வை மீண்டும் தொடங்கக்கூடியதாக விடுகிறது: --cookie. SIGUSR2 உடனடி மறுஇணைப்பை கட்டாயப்படுத்துகிறது. SIGKILL சுத்தத்தை முழுவதுமாகத் தவிர்க்கிறது, இந்தக் கட்டுரை பேசுவது சரியாக அந்த நிலையைப் பற்றியது.

resolv.conf-ஐ மாற்றாமல் resolver-ஐ சரிசெய்யுங்கள்

பெரும்பாலான Ubuntu கணினிகளில் /etc/resolv.conf systemd-resolved-க்கான குறியீட்டு இணைப்பு, நீங்கள் திருத்த வேண்டிய கோப்பு அல்ல. அதை மாற்றுவது VPN-க்கு மட்டுமல்ல, ஒவ்வொரு பிணையத்திற்கும் பெயர் தீர்வை உடைக்கிறது. அதற்குப் பதிலாக சுரங்கப்பாதையின் பதிவை அகற்றுங்கள்:

resolvectl revert tun0
resolvectl query example.com

கணினி systemd-resolved-க்குப் பதிலாக resolvconf-ஐப் பயன்படுத்தினால், ஒவ்வொரு இடைமுகத்திற்கான பதிவும் இணைப்பை விடச் சொல்லும் வரை நீடிக்கும், மேலும் resolvconf -d tun0 சமமான செயல். கட்டளையைத் தேர்ந்தெடுக்கும் முன் எந்த resolver பயன்படுத்தப்படுகிறது என்பதைச் சரிபாருங்கள்.

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

அடுத்த துண்டிப்பை சலிப்பானதாக்குங்கள்

தொடக்கம் மற்றும் நிறுத்தத்தில் pid கோப்பின் பாதையை ஒரே மாதிரியாக வைத்திருங்கள், ஒவ்வொரு முறையும் --pid-file வழங்குவதன் மூலம், அல்லது openconnect-ஐ unit ஒன்றின் கீழ் இயக்குங்கள் அதன் KillSignal உங்கள் பதிப்பு ஆவணப்படுத்தும் சிக்னலுடன் பொருந்துகிறது. முதலில் முன்னணியில் சோதிப்பது உதவியாளர் அச்சிடும் நிறுத்தச் செய்திகளைக் காட்டும்.

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

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