जब होस्ट बाहर जाने वाला 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 पते पर क्यों जवाब देता है।