प्रति प्रोफ़ाइल जाँच के साथ कई vpnc टनल चालू रखें

एक vpnc प्रोफ़ाइल रोमिंग के बाद साफ़ तौर पर फिर जुड़ती है; तीनों बारी-बारी से एक-दूसरे के सॉकेट, रूट और रिज़ॉल्वर की स्थिति तोड़ते हैं। पैकेज के साथ आने वाली रीकनेक्ट स्क्रिप्ट एक ही टनल के लिए लिखी गई है, इसलिए जब भी इनमें से कोई एक नीचे होती है तब वह हर प्रोफ़ाइल को फिर शुरू कर देती है। इसे ठीक करने के लिए तीन चीज़ें चाहिए: अलग लोकल पोर्ट, हर प्रोफ़ाइल के लिए असली सेवा जाँचने वाली एक जाँच, और एक क्रमबद्ध श्रृंखला जो कभी दो कनेक्शन एक साथ नहीं चलाती।

हर प्रोफ़ाइल को उसका अपना लोकल पोर्ट दें

डिफ़ॉल्ट लोकल पोर्ट पर छोड़ी गई vpnc प्रोफ़ाइल पहले से चल रही प्रोफ़ाइल से होड़ करती है। पहला पोर्ट थामे रहता है तब दूसरा कनेक्शन विफल होता है, और लॉग की पंक्ति लोकल टकराव के बजाय गेटवे की समस्या जैसी दिखती है। इसके बजाय हर प्रोफ़ाइल फ़ाइल के लिए एक पंक्ति रखें:

Local Port 0

शून्य कर्नेल को अल्पकालिक पोर्ट चुनने देता है, इसलिए दो प्रोफ़ाइल एक साथ बनाई जा सकती हैं। हर फ़ाइल का नाम उस गेटवे और समूह पर रखें जिसकी वह सेवा करती है, उसे केवल root के लिए पठनीय रखें, और हमेशा साझा डिफ़ॉल्ट के बजाय मिलती-जुलती प्रोफ़ाइल से जुड़ें। किसी के प्रोफ़ाइल का नाम बदलने के बाद साझा डिफ़ॉल्ट फ़ाइल ही वह तरीका है जिससे स्क्रिप्ट गलत टनल से फिर जुड़ती है।

प्रोफ़ाइल फ़ाइलें क्रेडेंशियल रखती हैं, इसलिए अनुमतियाँ डिज़ाइन का हिस्सा हैं, घर के काम की नहीं। /etc/vpnc के नीचे सबके पढ़ने योग्य फ़ाइल समूह का रहस्य हर लोकल उपयोगकर्ता को दे देती है। मोड 0600 रखें और मालिक root रखें, और स्क्रिप्टों को रहस्य आर्ग्युमेंट में नक़ल करने के बजाय फ़ाइल को root के रूप में पढ़ने दें। इसी कारण जाँच स्क्रिप्ट को कभी फ़ाइल की सामग्री लॉग में नहीं छापनी चाहिए।

हर प्रोफ़ाइल के लिए एक सेवा जाँचें, टनल का पता नहीं

टनल के अपने पते पर भेजा गया इको अनुरोध ज़्यादातर यही साबित करता है कि इंटरफ़ेस मौजूद है। यह नहीं बताता कि उसके पीछे का होस्ट अब भी उस एप्लिकेशन तक पहुँचता है जो टनल को जायज़ ठहराता है। इंटरफ़ेस ऊपर हो सकता है जबकि उसके आगे का रूट पहले ही जा चुका हो।

हर प्रोफ़ाइल के लिए एक सेवा छोटे TCP टाइमआउट के साथ जाँचें और केवल उसी प्रोफ़ाइल को फिर जोड़ें जिसकी जाँच विफल हुई। दो सेकंड मृत मार्ग को धीमे मार्ग से अलग करते हैं, और TCP जाँच इस पर निर्भर नहीं करती कि रास्ते में कहीं ICMP की अनुमति है या नहीं। प्रोफ़ाइलों के बीच केवल लक्ष्य और कॉन्फ़िग का नाम बदलें:

#!/bin/bash
set -eu
if ! nc -z -w 2 10.63.7.20 8443; then
  /usr/sbin/vpnc-connect ops.conf
fi

इसे /usr/local/bin/ensure-vpn-ops.sh के रूप में सहेजें, इसे निष्पादन योग्य बनाएँ, और हर प्रोफ़ाइल के लिए केवल जाँच का लक्ष्य और कॉन्फ़िग का नाम बदलकर दोहराएँ। जो जाँच प्रोटोकॉल के प्रश्न का उत्तर देती है वह ऐसे गेटवे से बच निकलती है जो इको गिरा देते हैं पर उपयोगकर्ताओं के लिए महत्वपूर्ण सेवाएँ अब भी आगे भेजते हैं।

जाँचों को श्रृंखला में जोड़ें ताकि वे कभी होड़ न करें

पैकेज के साथ आने वाली रीकनेक्ट स्क्रिप्ट आपकी जाँचों को क्रम में बुला सकती है, और क्रम ही पूरी बात है। साथ चलने वाली दो vpnc-connect कॉल रूटिंग तालिका को ऐसे क्रम में फिर लिखती हैं जिसे कोई नियंत्रित नहीं करता, और इसी तरह एक स्वस्थ प्रोफ़ाइल अपना रूट खो देती है।

कॉल को अग्रभूमि में रखें, नीचे के इंटरफ़ेस के लिए छोटा स्थिरता विलंब जोड़ें, और श्रृंखला को root की cron तालिका से नियत करें, क्योंकि केवल root ही टनल के रूट फिर लिख सकता है:

#!/bin/bash
sleep 20
/usr/local/bin/ensure-vpn-ops.sh
/usr/local/bin/ensure-vpn-lab.sh

बूट स्क्रिप्ट और cron प्रविष्टि के बीच क्रम एक जैसा रखें, क्योंकि बूट के समय अलग क्रम में चलने वाली श्रृंखला वास्तव में दूसरा प्रोग्राम है। जब एक प्रोफ़ाइल दूसरे के रूट पर निर्भर हो, तो निर्भरता को पहले रखें और बाद की जाँच को बिना नुकसान विफल होने दें जबकि पिछली टनल अब भी ऊपर आ रही हो।

लॉग पर नज़र रखें, फिर जानबूझकर एक तोड़ें

हर बार चलाने पर एक पंक्ति लॉग करें — प्रोफ़ाइल, जाँच का लक्ष्य, परिणाम और उठाया गया कदम। इसके बिना हर मिनट डगमगाती टनल बिल्कुल ऐसी दिखती है जो कभी गिरी ही नहीं, और जाँच की गड़बड़ी गेटवे की रुकावट से अलग नहीं पहचानी जा सकती। लॉग यह भी साबित करता है कि श्रृंखला ने केवल उसी प्रोफ़ाइल को छुआ जो विफल हुई। इसे ऐसी जगह लिखें जो रीबूट के बाद भी बची रहे, वरना सबूत प्रक्रिया के साथ चला जाता है।

फिर जानबूझकर एक टनल तोड़ें और देखें क्या होता है। एक ही प्रोफ़ाइल रोकें और पुष्टि करें कि कौन-सी प्रक्रियाएँ और रूट अब भी मौजूद हैं:

pgrep -a vpnc
ip -4 route show | grep -E '10[.]63|10[.]90'
tail -n 5 /var/log/ensure-vpn.log

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

पहरेदार को क्या नहीं करना चाहिए

जो पहरेदार कुछ भी विफल होने पर सब कुछ फिर शुरू कर देता है वह परीक्षण के दौरान स्वस्थ दिखता है और रखरखाव विंडो में रुकावट पैदा करता है। प्रोफ़ाइल के हिसाब से फिर शुरू करें, कभी वैश्विक रूप से नहीं।

जब गेटवे उसी प्रोटोकॉल के लिए अनुरक्षित क्लाइंट देता है तब उसे प्राथमिकता दें, और कभी स्क्रिप्ट में पासवर्ड हार्डकोड न करें और न ही कमांड लाइन पर भेजें, क्योंकि प्रोफ़ाइल फ़ाइल पहले ही रहस्य रखती है। अगर टनल ऊपर आने के बाद कोई काम साधारण उपयोगकर्ता के रूप में चलाना हो, तो पूरी श्रृंखला उस खाते के नीचे चलाने के बजाय स्क्रिप्ट के भीतर से विशेषाधिकार घटाएँ। अंत में, फिर जुड़ने के बाद रूट फिर पढ़ें, क्योंकि प्रोफ़ाइल अलग आवंटित पता लेकर लौट सकती है और एक पुराना रूट छोड़ सकती है जिसे टनल के पते की ओर बढ़ने वाली कोई जाँच कभी नहीं देख पाएगी।