होस्टले बाहिर जाने VPN चलाउँदा स्थानीय SSH कायम राख्नुहोस्

एउटा सानो Linux सर्भरले आफूले होस्ट गरेको अनुप्रयोगका लागि बाहिर जाने VPN चलाउँछ, र प्रशासक अझै पनि छेउको टेबलबाट SSH मार्फत त्यहाँ पुग्न चाहन्छ। यो उचित आवश्यकता हो, र सामान्यतया यसलाई पोर्ट फर्वार्डिङ, प्रदायकको ठेगाना वा सुरुङमा कुनै प्वाल आवश्यक पर्दैन। आवश्यक पर्ने भनेको जानाजान डिजाइन गरिएको व्यवस्थापन मार्ग हो, VPN क्लाइन्टले राउटिङ तालिकासँग गरेको कुराबाट उत्तराधिकारमा प्राप्त नहुने।

तलका चरणहरूले प्रशासक उही LAN मा छ भनी मान्छन्।टाढाको प्रशासन फरक उत्तर भएको फरक समस्या हो।

SSH लाई प्रशासकहरूले प्रयोग गर्ने ठेगानामा बाँध्नुहोस्

लिसनरबाट सुरु गर्नुहोस्।ss -ltnp | grep :22 sshd कसमा बाँधिएको छ देखाउँछ, र 0.0.0.0 मा रहेको लिसनरले सुरुङसहित हरेक इन्टरफेसबाट जडान स्वीकार गर्छ। LAN ठेगानामा बाँध्नु अझ साँघुरो छ र मनसाय देखिने बनाउँछ:ListenAddress 192.168.10.20 भित्र sshd_config, त्यसपछि कन्फिगरेसन परीक्षण र पुनः लोड। त्यो ठेगानामा टाइपो वाइल्डकार्डभन्दा बढी देखिन्छ, किनकि ठेगाना नभएपछि sshd सुरु हुन इन्कार गर्छ।

होस्ट-की जाँच र प्रति-प्रयोगकर्ता प्रमाणीकरण जस्तो छ त्यस्तै राख्नुहोस्। “यो केवल स्थानीय सञ्जाल हो” प्रमाणीकरण विधि होइन, र मार्ग छोटो भएकाले कुञ्जी जाँच छोड्ने व्यवस्थापन च्यानल दुरुपयोगको प्रतीक्षा गर्ने च्यानल हो। DHCP आरक्षण वा स्थिर ठेगानाले लक्ष्यलाई अनुमानयोग्य बनाउँछ, त्यसलाई सर्भरको सार्वजनिक पहिचान नबनाई।

LAN मार्ग सुरुङबाहिर राख्नुहोस्

192.168.10.0/24 मा ठेगाना भएको होस्टसँग त्यो प्रिफिक्सका लागि जोडिएको मार्ग हुन्छ, र त्यही तालिकामा अझ विशिष्ट मार्गले VPN को पूर्वनिर्धारितलाई हराउँछ। त्यसैले सुरुङ माथि आउँदा स्थानीय SSH प्रायः आफैं चलिरहन्छ। अनुमान गर्नुको सट्टा यो जाँच्नुहोस्:ip route get 192.168.10.50 कर्नलले प्रयोग गर्ने इन्टरफेस र स्रोत ठेगानाको नाम बताउँछ, र उत्तर सुरुङ नभई LAN उपकरण हुनुपर्छ। प्रशासकको मेसिनबाट पनि जाँच दोहोर्याउनुहोस्, किनकि प्याकेट पुग्छन् कि पुग्दैनन् भन्ने उसको आफ्नै तालिकाले निर्धारण गर्छ। एउटै तारमा रहेका दुई होस्ट कुन दिशा पुग्न सकिन्छ भन्नेमा असहमत हुन सक्छन्।

अनुमान दुई ठाउँमा टुट्छ। नीति-आधारित राउटिङ नियमले मुख्य तालिका हेर्नुअघि पूर्वनिर्धारित सुरुङतिर देखाउने तालिकामा ट्राफिक पठाउन सक्छ। लकडाउन वा kill switch सुविधा भएको VPN क्लाइन्टले सुरुङमा नपस्ने ट्राफिक पनि रोक्न सक्छ, राउटिङ तालिकाले जे भने पनि।

राउटेड व्यवस्थापन VLAN अर्को अवस्था हो। प्रशासक स्थानीय राउटरपछि 192.168.50.0/24 मा बस्छ भने सर्भरलाई त्यो प्रिफिक्सका लागि 192.168.10.1 मार्फत स्पष्ट मार्ग चाहिन्छ, र त्यो मार्ग पुनः जडानमा टिक्नुपर्छ। अपवादलाई व्यवस्थापन प्रिफिक्समै सीमित राख्नुहोस्; निजी दायराका लागि व्यापक अपवादले सुरुङको उद्देश्य विफल बनाउँछ।

फायरवाल अपवादलाई नियमजत्तिकै साँघुरो बनाउनुहोस्

होस्टमा फायरवाल चल्छ भने SSH लाई व्यवस्थापन स्रोतबाट मात्र र LAN इन्टरफेसमा मात्र अनुमति दिनुहोस्। जुन नियमले 22 पोर्टलाई जहाँबाट पनि अनुमति दिन्छ त्यो आवश्यकताभन्दा फराकिलो छ र समीक्षामा औचित्य पुष्टि गर्न गाह्रो। nftables होस्टमा नियम इन्टरफेस र स्रोत मिलाएर इनपुट चेनमा रहन्छ; iptables होस्टमा समतुल्य -i र -s मा दुई मिलानको जोडी हो। नियममा यसले सेवा गर्ने प्रशासक समूहको टिप्पणी लेख्नुहोस्, ताकि अर्को अडिटले 22 पोर्ट किन खुला छ भनेर अनुमान गर्नु नपरोस्।

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

दुवै अवस्था परीक्षण गर्नुहोस्

परीक्षण दुई पटक चलाउनुहोस्: एक पटक सुरुङ जोडिएको अवस्थामा र एक पटक विच्छेद भएको अवस्थामा। हरेक अवस्थामा लिसनर, मार्ग र प्रशासकको मेसिनबाट वास्तविक SSH लगइन पुष्टि गर्नुहोस्। जुन मार्ग सुरुङ माथि हुँदा मात्र चल्छ त्यो स्थानीय व्यवस्थापन मार्ग होइन; त्यो संयोग हो।

त्यसपछि SSH सत्र खुला रहँदा सुरुङ पुनः सुरु गर्नुहोस्। जो सत्र टिक्छ त्यसले राउटिङ स्थिर रहेको प्रमाण दिन्छ; जो सत्र टुट्छ त्यसले क्लाइन्टले पुनः जडानमा मार्ग वा फिल्टर फेरि लेखिरहेको बताउँछ, जुन घटनाको बेला नभई अघि जान्न योग्य छ।

तपाईंले परीक्षण गर्नुभएको स्रोत ठेगाना टिप्नुहोस्, किनकि 192.168.10.50 का लागि लेखिएको नियम प्रशासकको ल्यापटप अर्को सबनेटमा गएपछि चुपचाप विफल हुन्छ।

पुनर्प्राप्ति मार्ग runbook मा लेख्नुहोस्

बाहिर जाने VPN ले स्थानीय मार्ग तोड्यो भने के हुन्छ अहिले नै निर्णय गर्नुहोस्। कन्सोल पहुँच, दोस्रो व्यवस्थापन ठेगाना वा क्लाइन्ट रोक्ने लिखित प्रक्रिया — सबै वैध उत्तर हुन्, र तीमध्ये कुनै पनि लगइन गर्नुपर्ने क्षणमा समस्या पत्ता लगाउनुभन्दा राम्रो छ। सर्भर टाढा छ भने स्थानीय मार्ग हुँदैन, र सही डिजाइन खुला सार्वजनिक पोर्ट नभई छुट्टै स्वीकृत टाढा-पहुँच मार्ग वा बास्टियन हो।

कागजातमा दुवै भूमिका छुट्टाछुट्टै राख्नुहोस्: नजिकैको प्रशासकका लागि स्थानीय SSH, र अनुप्रयोगको ट्राफिकका लागि बाहिर जाने सुरुङ। ती भूमिका लेखिएपछि भविष्यमा कुनैमा गरिने परिवर्तन जाँच्ने स्पष्ट ठाउँ हुन्छ, र अर्को व्यक्तिले VPN भएको सर्भर अझै पनि आफ्नो LAN ठेगानामा किन जवाफ दिन्छ भनेर फेरि पत्ता लगाउनु पर्दैन।