SSH के ज़रिए VPN क्लाइंट चला रहे हैं? पहले अपना रूट पिन करें

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

शुरू करने से पहले पथ दर्ज करें

ip route show default वर्तमान गेटवे और इंटरफ़ेस बताता है, जबकि ip route get 203.0.113.9 दिखाता है कि कर्नेल आपके सत्र के लिए कौन-सा इंटरफ़ेस और स्रोत पता इस्तेमाल करेगा। दोनों आउटपुट रखें। टनल के ऊपर आने के बाद भी उन दोनों कमांडों को भौतिक पथ का वर्णन करना चाहिए, और यदि वे इसके बजाय टनल का वर्णन करें, तो सत्र पहले से ही उधार लिए समय पर जी रहा है।

पहले से स्थापित कनेक्शन ही मायने रखता है, इसलिए केवल नए लॉगिन से सत्यापित न करें। नया सत्र कुछ समय के लिए उस स्थिति से सफल हो सकता है जो पुराने के पास अब नहीं है।

पता क्लाइंट के अपने कॉन्फ़िगरेशन में पिन करें

हाथ से जोड़ा गया रूट रीबूट पर गायब हो जाता है और क्लाइंट के अपने तालिका अपडेट से होड़ करता है, इसलिए अपवाद वहाँ रखें जहाँ तालिका प्रबंधित होती है। OpenVPN के अंतर्गत net_gateway कीवर्ड उस गेटवे में हल होता है जो टनल से पहले था, इसलिए route 203.0.113.9 255.255.255.255 net_gateway ठीक एक पता उसके बाहर रखता है। WireGuard को अलग दृष्टिकोण चाहिए क्योंकि wg-quick रूट खुद प्रबंधित करता है: Table = off सेट करें और PostUp में अपवाद जोड़ें, साथ में उसे हटाने वाला मेल खाता PostDown रखें। दोनों रूप एक ही मंशा व्यक्त करते हैं, और दोनों अपवाद को सब कुछ के लिए टनल कमज़ोर करने के बजाय एक पते तक सीमित रखते हैं।

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

या मुख्य तालिका को बहस से बाहर करें

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

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

मान लें कि पिनिंग विफल हो सकती है

आपके वर्तमान सार्वजनिक पते से बँधा रूट उसी क्षण टूट जाता है जब आपका प्रदाता उसे फिर से आवंटित करता है। तब दूरस्थ सर्वर को ऐसा पथ चाहिए जो उस पते पर निर्भर न हो: एक कंसोल, दूसरा प्रबंधन इंटरफ़ेस, या ऐसा जंप होस्ट जो टनल के बाहर रहे।

दो सुरक्षा उपाय दस मिनट लेते हैं। यदि कुछ मिनटों में पुष्टि लॉगिन न आए तो क्लाइंट को रोकने वाला वॉचडॉग लॉकआउट को विलंब में बदल देता है, और बदलाव के दौरान खुला रखा गया दूसरा SSH सत्र साबित करता है कि टनल ऊपर रहते हुए अपवाद काम करता है। अकेले keepalive यहाँ मदद नहीं करते, क्योंकि पथ निष्क्रिय नहीं बल्कि चला गया है; वे केवल मृत्यु को नोटिस करना आसान बनाते हैं।

उसी क्रम में सत्यापित करें जो मायने रखता है

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

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