अकेला स्लीप हुक VPN को वापस नहीं लाएगा

स्लीप हुक में एक पुनःकनेक्ट आदेश डालें और समस्या सुलझी हुई लगती है। यह तभी सुलझती है जब हुक नेटवर्क मौजूद होने के बाद चले, ऐसी पहचान के रूप में जिसे क्लाइंट पहचानता है, ऐसे रास्ते से जिसे क्लाइंट वास्तव में लागू करता है। फिर से शुरू होने के बाद की अधिकांश विफलताएँ उन तीन में से एक होती हैं, और उनमें से कोई भी हुक में ही त्रुटि के रूप में नहीं दिखती। हुक किसी भी तरह सफलता लौटाता है।

शून्य के साथ बाहर निकलने वाली स्क्रिप्ट ने आपको यह नहीं बताया कि कोई टनल वापस आई या नहीं।

हुक चलता है, और फिर क्या?

#!/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 अभी फिर से जुड़ रहा हो, जिससे कोई भी निश्चित स्लीप अनुमान बन जाती है। किसी पहुँच योग्य पते की प्रतीक्षा करें, फिर प्रोफ़ाइल ऊपर उठाएँ, और प्रतीक्षा को सीमित करें ताकि हुक फिर से शुरू होने का रास्ता अनिश्चितकाल तक खुला न रख सके। संख्यात्मक सूचकांक के बजाय प्रोफ़ाइल का नाम पसंद करें, और यदि सही प्रोफ़ाइल नेटवर्क के अनुसार बदलती है, तो स्वस्थ टनल अपनी पसंद पहले से एक फ़ाइल में दर्ज करे।

रीस्टार्ट तूफ़ानों से भी बचें, प्रयासों की गिनती करके और रुककर। हर असफल जाँच पर प्रतिक्रिया देने वाला वॉचडॉग एक व्यवधान को लूप में बदल देता है।

एक बार सस्पेंड करें, फिर जर्नल में हुक के अपने आउटपुट के लिए पढ़ें। यही एकमात्र परीक्षण है जो क्रम साबित करता है।