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 येथे मदत करत नाहीत, कारण मार्ग निष्क्रिय नाही तर गेला आहे; ते मृत्यू लक्षात घेणे सोपे करतात।

महत्त्वाच्या क्रमाने पडताळणी करा

टनल जोडा, तुमच्या पत्त्याकडील रूट अजूनही भौतिक गेटवेमधून बाहेर पडतो याची खात्री करा, मग नवीन सेशन उघडा। जर नवीन सेशन चालले आणि जुने तरीही मरण पावले, तर कारण राउटिंग नाही तर कनेक्शन ट्रॅकिंग किंवा स्थितीय फायरवॉल आहे, जो वेगळा उपाय आहे।

पिन केलेला पत्ता आणि तो सिद्ध करणारा आदेश बदल-नोंदीत लिहा। त्या होस्टवर पुढे क्लायंट सुरू करणाऱ्या व्यक्तीला दोन्ही लागतील, आणि तोपर्यंत पत्ता बदललेला असू शकतो।