बोगदा बंद आहे, पण मशीन अजूनही तो सुरू असल्यासारखे वागते: एक लुकअप टाइमआउट होईपर्यंत लटकत राहतो, आणि एक रूट आता नसलेल्या इंटरफेसकडे निर्देश करते। हे अशा openconnect प्रक्रियेचे लक्षण आहे जी तिच्या डिस्कनेक्ट हेल्परला न चालवता मेली। तिने तयार केलेली नेटवर्क स्थिती अजूनही स्थापित आहे, आणि सिस्टममधील दुसऱ्या कशालाही ती कशी काढायची हे माहीत नाही।

स्थिती ज्या क्रमाने तयार झाली त्या क्रमाने मशीनमधून जा: प्रक्रिया, लिंक, रूट, रिझोल्व्हर। प्रत्येक पायरी सांगते की क्लायंट खरोखर गेला आहे की फक्त तुमच्या टर्मिनलपासून वेगळा झाला आहे, आणि हा फरकच काही दुरुस्त करायचे की नाही हे ठरवतो।

प्रक्रियेपासून सुरुवात करा, कॉन्फिगरेशनपासून नाही

रूटला हात लावण्यापूर्वी टर्मिनल उघडा आणि अजून काय चालू आहे ते विचारा। pgrep -a openconnect प्रत्येक इन्स्टन्स त्याच्या आर्ग्युमेंट्ससह सूचीबद्ध करते, जे pid फाइल आणि त्याला दिलेली स्क्रिप्ट दाखवते। जी प्रक्रिया तुम्ही अपेक्षित नव्हती ती कोणत्याही लॉगपेक्षा वेगाने फँटम बोगदा समजावते।

काहीही चालू नसल्यास, लिंक पहा। ip link show tun0 इंटरफेस टिकली का हे सांगते, आणि ip route show dev tun0 अजूनही त्याला जोडलेले रूट सूचीबद्ध करते। नंतर रिझोल्व्हर याने तपासा resolvectl status। बदलण्यापूर्वी तिन्ही आउटपुट नोंदवा, कारण तीच नोंद नंतर जुनी नोंद नव्यापासून वेगळी करण्याचा मार्ग आहे।

गेलेला इंटरफेस सहसा त्याचे रूट सोबत घेऊन जातो। लिंकनंतर टिकणारे रूट सहसा प्रक्रिया अजूनही जिवंत आहे किंवा दुसरा क्लायंट डिव्हाइसचा मालक आहे असे अर्थ देतात।

बदल परत आणणारी हेल्पर स्क्रिप्टच असते

openconnect स्वतः इंटरफेस, रूट किंवा रिझोल्व्हर नोंदी काढत नाही। ते बाह्य हेल्परला बोलावते, /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 न बदलता रिझोल्व्हर दुरुस्त करा

बहुतेक Ubuntu सिस्टमवर /etc/resolv.conf systemd-resolved कडे जाणारी सिम्बॉलिक लिंक आहे, तुम्ही संपादित करावयाची फाइल नाही। ती बदलल्याने फक्त VPN नाही तर प्रत्येक नेटवर्कचे नाव रिझोल्यूशन तुटते। त्याऐवजी बोगद्याची नोंदणी काढा:

resolvectl revert tun0
resolvectl query example.com

सिस्टम systemd-resolved ऐवजी resolvconf वापरत असल्यास, प्रत्येक इंटरफेसची नोंद लिंक सोडण्यास सांगेपर्यंत राहते, आणि resolvconf -d tun0 समतुल्य क्रिया आहे। आदेश निवडण्यापूर्वी कोणता रिझोल्व्हर वापरला जातो ते तपासा।

मृत लिंकच्या मागील सर्व्हरकडे अजूनही लक्ष्य असलेला लुकअप टाइमआउट होईपर्यंत लटकत राहतो, आणि तो उशीर उरलेल्या रूटपेक्षा तुटलेल्या DNS सर्व्हरसारखा वाटतो।

पुढील डिस्कनेक्ट कंटाळवाणे करा

स्टार्टअप आणि शटडाउनमध्ये pid फाइलचा मार्ग समान ठेवा, प्रत्येक वेळी --pid-file देऊन, किंवा openconnect unit अंतर्गत चालवा ज्याचा KillSignal तुमची आवृत्ती दस्तऐवजीकरण करते त्या सिग्नलशी जुळतो। प्रथम फोरग्राउंडमध्ये चाचणी केल्यास हेल्पर छापत असलेले शटडाउन संदेश दिसतात।

कनेक्ट करा, डिस्कनेक्ट करा आणि तीन तपासण्या एकदा चालवा। स्वच्छ निर्गती VPN लिंक, VPN रूट किंवा VPN रिझोल्व्हर नोंद ठेवत नाही। तिन्हींपैकी एक टिकून राहिला तर कोणता घटक स्वच्छ करू शकला नाही हे आता तुम्हाला माहीत आहे। पुढील तपासणी मग लटकलेल्या लुकअपपासून नाही, त्या उत्तरापासून सुरू होते।

संबंधित लेख