पूरा टनल मार्ग उसे ढोने वाले सर्वर को क्यों काट देता है

पूरा टनल चालू करें और अब हर गंतव्य VPN इंटरफ़ेस का है, जिसमें वह मशीन भी शामिल है जो इसे समाप्त करती है। टनल ढोने वाले बाहरी पैकेट उसी मशीन को संबोधित हैं, इसलिए मार्ग अंततः उसी परिवहन को खा जाता है जिस पर वह निर्भर है। एक अतिरिक्त विशिष्ट मार्ग इसे हल करता है, और कारण समझने लायक है। उस कारण के बिना अगला पुनर्निर्माण वही खराबी फिर ले आता है।

ऐसा मार्ग जो अपना ही परिवहन खा जाए

एनकैप्सुलेशन हर पैकेट को दूसरे हेडर में लपेटता है। बाहरी हेडर स्थानीय भौतिक पते से सर्वर के सार्वजनिक पते तक संबोधित है, और कोई भी टनल बनने से पहले उसे भौतिक लिंक पार करना होता है।

अब उस सार्वजनिक पते की खोज को टनल चुनने दें। पैकेट भेजने के लिए मशीन को उसे एनकैप्सुलेट करना होता है, जिसके लिए उसी पते तक मार्ग चाहिए, जो टनल लौटाता है। क्लाइंट इसे दो तरीकों में से एक से संभालते हैं। सतर्क क्लाइंट डिफ़ॉल्ट मार्ग लगाने से इंकार करता है और त्रुटि बताता है, जबकि कम सतर्क क्लाइंट सफलता बताता है और फिर कुछ भी नहीं हिलाता। ख़ामोश विफलता वही है जो एक दोपहर खाती है।

सबसे लंबे प्रीफ़िक्स का मेल किसी भी मीट्रिक को देखने से पहले खोज तय कर देता है, इसलिए एक-पते का मार्ग मशीन के हर डिफ़ॉल्ट मार्ग से आगे निकल जाता है। मरम्मत के पीछे पूरा तंत्र यही है।

डिफ़ॉल्ट से पहले अपवाद लगाएँ

सर्वर के लिए एक-पते का मार्ग बनाएँ, भौतिक गेटवे को अगली छलांग रखकर, इससे पहले कि डिफ़ॉल्ट मार्ग हिले। क्रम मायने रखता है: बाद में लगाना यानी टाइप करते समय टूटी टनल के साथ जीना।

ज़्यादातर क्लाइंट यह बिना कहे करते हैं। OpenVPN दूर के पते को खोजता है और डिफ़ॉल्ट गेटवे फिर से लिखने से पहले उसे पिन करता है, और इसका route-delay विकल्प उन प्लेटफ़ॉर्म के लिए है जहाँ यह क्रम दौड़ता है। wg-quick बिल्कुल अलग रास्ता लेता है, पैकेटों को चिह्नित करके और नीति नियम से परामर्श करके अपवाद जोड़ने के बजाय। अलग तंत्र, एक ही ज़रूरत: बाहरी पैकेट को उस टनल से बचना ही होगा जो वह बनाता है।

ip route add 203.0.113.10/32 via 192.168.1.1 dev eth0
ip route get 203.0.113.10

खोज का आउटपुट स्वीकृति परीक्षा है। उसमें भौतिक उपकरण और भौतिक अगली छलांग का नाम होना चाहिए। उस उत्तर में टनल उपकरण होने का अर्थ है कि अपवाद गायब है, या ऐसी किसी चीज़ के बाद रखा गया है जो उसे दरकिनार करती है।

सर्वर पर दर्पण प्रतिबिंब

वही जाल दूसरी तरफ़ उलटा इंतज़ार करता है। सर्वर को दूसरी टनल के ज़रिए डिफ़ॉल्ट मार्ग दें, या उसकी ओर ऐसा मार्ग धकेलें जो क्लाइंटों के सार्वजनिक पतों को ढकता हो, और उसके उत्तर ग़लत दिशा की आदत अपना लेंगे।

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

ip route get 198.51.100.44 from 10.90.0.1
ip rule show
sudo tcpdump -ni any host 198.51.100.44

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

ऐसे अपवाद जिन्हें टनल लगातार चुराता है

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

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

जिस अपवाद को किसी ने लिखा नहीं, वह ऐसा अपवाद है जिसे अगला पुनर्निर्माण ख़ामोशी से गिरा देगा।

इसे फिर से जुड़ने के बाद साबित करें, पहले नहीं

तीन गंतव्य जाँचें, एक नहीं: एंडपॉइंट, टनल के पीछे एक निजी पता, और उसके पार एक सार्वजनिक पता। एक सफल खोज बाकी दोनों के बारे में लगभग कुछ नहीं कहती।

ip route get 203.0.113.10
traceroute -n 203.0.113.10
ip route get 10.90.0.5
ip route get 1.1.1.1

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