होस्ट बाहेर जाणारा 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 पत्त्यावर का प्रतिसाद देतो हे पुन्हा शोधावे लागत नाही।