स्लीप हुकमध्ये पुन्हा कनेक्टचा आदेश टाका आणि समस्या सुटलेली दिसते. ती तेव्हाच सुटते जेव्हा हुक नेटवर्क अस्तित्वात आल्यानंतर चालतो, क्लायंट ओळखतो अशा ओळखीने, आणि क्लायंट प्रत्यक्षात राबवतो अशा मार्गाने. पुन्हा सुरू झाल्यानंतरचे बहुतेक अपयश या तीनपैकी एक असते, आणि त्यातले कोणतेही हुकमध्ये स्वतः त्रुटी म्हणून दिसत नाही. हुक कोणत्याही परिस्थितीत यश परत देतो.

शून्यासह बाहेर पडणाऱ्या स्क्रिप्टने तुम्हाला टनेल परत आले की नाही याबद्दल काहीही सांगितले नाही.

हुक चालतो, आणि मग काय?

#!/bin/sh
case "$1" in
  pre)
    vpn-client disconnect
    ;;
  post)
    vpn-client connect
    ;;
esac

प्रत्येक घटना हुकला दोन वेळा बोलावते — संक्रमणापूर्वी आणि नंतर — आणि त्याला टप्पा व घटनेचे नाव देते. तो किमान वातावरणात root म्हणून चालतो, म्हणून पूर्ण मार्ग आवश्यक आहेत आणि डेस्कटॉप सत्राचा कोणताही चल अपेक्षित धरू नये. दोन्ही कॉल लवकर परत येणे फक्त स्क्रिप्ट चालली हे सांगते. त्यानंतर प्रोफाइल वर आले का हे वेगळे निरीक्षण आहे आणि लॉगमध्ये त्याचा स्वतःचा पुरावा हवा.

टप्प्याच्या वितर्काला रचनेचा भाग माना. pre टप्प्यातील पुन्हा कनेक्टचा प्रयत्न तेव्हा होतो जेव्हा यंत्र सर्व गमावणार असते, आणि तो यशस्वी होऊ शकत नाही.

Root, किमान वातावरण, चुकीचा वापरकर्ता

क्लायंट प्रत्येक वापरकर्त्यासाठी लॉगिन टोकन ठेवत असेल, तर हुक root म्हणून चालवल्यास त्याच्याकडे सादर करण्यास काहीही उरत नाही. हुक प्रत्यक्षात वापरतो त्या ओळखीखाली स्थिती तपासा, डेस्कटॉप टर्मिनलवरून तुम्ही तपासलेल्या ओळखीखाली नाही. काही बिल्ड डिस्कनेक्टनंतर इंटरफेस धरून ठेवणारा डेमनही सोडतात, त्यामुळे पुन्हा कनेक्ट जुन्या स्थितीत पडते, आणि आधी प्रक्रिया साफ केल्यास ती अस्वच्छ बंदीच्या किंमतीवर पुनर्संचयित होते. फक्त आनंददायी मार्ग तपासल्यास दोन्हीपैकी कोणतेही वर्तन दिसत नाही.

हुक पूर्ण मार्गांसह लिहा, तो root च्या मालकीखाली आणि कार्यान्वित ठेवा, आणि त्याने काय केले ते लॉग करा. त्या लॉगशिवाय पुढील तपास शून्यापासून सुरू होते.

स्वयंकनेक्ट VPN चा मार्ग नाही

NetworkManager दोन सक्रियकरण यंत्रणा देते: प्रोफाइलवर स्वयंकनेक्ट ध्वज, आणि प्राथमिक प्रोफाइल सक्रिय झाल्यावर सुरू होणारी दुय्यम कनेक्शन. मूळ उपकरण प्रकार पहिले राबवतात; VPN प्लगइननी ऐतिहासिकदृष्ट्या फक्त दुसरे राबवले आहे, त्यामुळे OpenVPN प्रोफाइलवर स्वयंकनेक्ट टिक करण्याचा काहीच परिणाम होऊ शकत नाही. दोन्ही गुणधर्म तपासा, नंतर VPN Wi-Fi किंवा Ethernet प्रोफाइलच्या दुय्यम म्हणून जोडा.

[Unit]
PartOf=NetworkManager.service
Requires=NetworkManager-wait-online.service
After=NetworkManager-wait-online.service

systemd युनिटद्वारे व्यवस्थापित WireGuard इंटरफेसला हुकऐवजी तो ड्रॉप-इन हवा, नेटवर्क ऑनलाइन झाल्यानंतर क्रमवारीत.

नेटवर्कची प्रतीक्षा करा, मर्यादेसह

timer=1
while ! ping -c1 -n -w1 203.0.113.1 >/dev/null; do
  sleep 1; timer=$((timer+1))
  [ $timer -ge 300 ] && exit 0
done
nmcli connection up "work-vpn"

पुन्हा सुरू होताना Wi-Fi अजून पुन्हा जोडत असतानाच टनेलची मागणी होऊ शकते, ज्यामुळे कोणतीही निश्चित स्लीप अंदाज बनते. पोहोचण्यायोग्य पत्त्याची प्रतीक्षा करा, नंतर प्रोफाइल वर आणा, आणि प्रतीक्षा मर्यादित करा जेणेकरून हुक पुन्हा सुरू होण्याचा मार्ग अनिश्चित काळासाठी उघडा ठेवू शकणार नाही. संख्यात्मक निर्देशांकापेक्षा प्रोफाइलचे नाव पसंत करा, आणि योग्य प्रोफाइल नेटवर्कनुसार बदलत असेल, तर निरोगी टनेलने त्याची निवड आधीच फाइलमध्ये नोंदवावी.

रीस्टार्ट वादळांपासूनही बचा, प्रयत्न मोजून आणि थांबून. प्रत्येक अयशस्वी तपासणीला प्रतिसाद देणारा वॉचडॉग एक व्यत्यय लूपमध्ये बदलतो.

एकदा सस्पेंड करा, नंतर हुकच्या स्वतःच्या आउटपुटसाठी जर्नल वाचा. क्रम सिद्ध करणारी ती एकमेव चाचणी आहे.

संबंधित लेख