फुल टनल ने आपका SSH सत्र मार डाला: वापसी मार्ग पिन करें

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

redirect-gateway वास्तव में क्या स्थापित करता है

अपने def1 रूप में redirect-gateway डिफ़ॉल्ट मार्ग को फिर से लिखने के बजाय 0.0.0.0/1 और 128.0.0.0/1 जोड़ता है। ये दोनों आधे पूरे पता-स्थान को कवर करते हैं और दोनों 0.0.0.0/0 से लंबे प्रीफ़िक्स बने रहते हैं, इसलिए अधिक विशिष्ट मेल के बिना कोई भी गंतव्य अब टनल में चला जाता है। यही वह तंत्र है जिसे याद रखना चाहिए, क्योंकि नीचे का हर सुधार अधिक विशिष्ट मेल स्थापित करके काम करता है।

आपका प्रशासनिक पता उन्हीं गंतव्यों में से एक है।

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

ip route show table main | head -n 20
ip route get 198.51.100.23

अपना स्रोत पता और टनल से पहले का मार्ग खोजें

सर्वर पर स्थापित SSH कनेक्शन सूचीबद्ध करें और वह पीयर पता नोट करें जिससे वह आया। वही पता है जिसे आपके वापसी मार्ग को कवर करना है, और वह हमेशा वही नहीं होता जो आप सोचते हैं: जंप होस्ट, NAT गेटवे या ऑपरेटर का अनुवादक कोई दूसरा स्रोत रख सकते हैं।

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

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

आधे-डिफ़ॉल्ट से आगे निकलने वाला होस्ट मार्ग पिन करें

एक /32 मार्ग दोनों आधे-डिफ़ॉल्ट में से किसी से भी लंबा है, इसलिए आपके पते पर आने वाले उत्तर टनल के बजाय उसे लेते हैं। अगला हॉप टनल से पहले का गेटवे है और डिवाइस भौतिक इंटरफ़ेस है, जो पैकेट को उसी रास्ते पर रखता है जो उसने टनल के अस्तित्व से पहले इस्तेमाल किया था।

ip route add 198.51.100.23/32 via 203.0.113.1 dev eth0

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

OpenVPN पहले से ही VPN सर्वर के अपने पते तक एक होस्ट मार्ग इसी कारण जोड़ता है, इसलिए यह पैटर्न परिचित है और प्रशासनिक पता बस एक और अपवाद है। इसे ठीक करने के लिए route-nopull का सहारा न लें, क्योंकि यह टनल को ज़रूरी उन धकेले गए मार्गों को फेंक देता है, जिनमें दूरस्थ नेटवर्क और DNS विकल्प भी शामिल हैं।

इसे पुनः कनेक्शन में टिकने दें

हाथ से जोड़ा गया मार्ग तब गायब हो जाता है जब क्लाइंट फिर से जुड़ता है और अपना स्थापित करता है, जो सुधार को बार-बार होने वाली रुकावट बना देता है। कमांड को किसी ऐसी चीज़ से जोड़ें जो मार्ग स्थापित होने के बाद चले।

एक route-up स्क्रिप्ट और नेटवर्क मैनेजर का pre-up हुक, दोनों काम करते हैं, और भरोसेमंद जाँच पुनः कनेक्शन के बाद वही लुकअप है।

Windows पर समकक्ष -p से जोड़ा गया स्थायी मार्ग है, जो रीबूट में टिकता है पर नेटवर्क बदलने के बाद भी सही गेटवे की ओर इंगित करना पड़ता है। प्लेटफ़ॉर्म जो भी हो, मार्ग के बगल में कारण लिखें: अगले प्रशासक को पता होना चाहिए कि यह प्रशासनिक सत्र की रक्षा के लिए है, इसलिए नहीं कि नेटवर्क डिज़ाइन ने इसे अनिवार्य किया था।

जब पिन किया गया मार्ग अभी भी पर्याप्त न हो

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

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

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