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 ले यहाँ मद्दत गर्दैन, किनकि बाटो निष्क्रिय नभई गइसकेको छ; तिनले मृत्यु सजिलै थाहा पाउन मात्र मद्दत गर्छन्।

महत्त्वपूर्ण क्रममा प्रमाणित गर्नुहोस्

टनेल जोड्नुहोस्, तपाईंको ठेगानातर्फको रुट अझै भौतिक गेटवेबाट बाहिर जान्छ भनी पुष्टि गर्नुहोस्, त्यसपछि नयाँ सत्र खोल्नुहोस्। यदि नयाँ सत्र चल्छ र पुरानो तैपनि मर्छ भने, कारण रुटिङ होइन, जडान ट्र्याकिङ वा स्थितियुक्त फायरवाल हो, जुन फरक समाधान हो।

पिन गरिएको ठेगाना र त्यो प्रमाणित गर्ने कमाण्ड परिवर्तन-रेकर्डमा लेख्नुहोस्। त्यो होस्टमा अर्को पटक क्लाइन्ट सुरु गर्ने व्यक्तिलाई दुवै चाहिन्छ, र तोपर्यन्त ठेगाना बदलिएको हुन सक्छ।