पूर्ण बोगद्याने तुमचे SSH सत्र मारले: परतीचा मार्ग पिन करा

तुम्ही SSH वरून काम करत असलेल्या मशीनवर OpenVPN क्लायंट सुरू करा, आणि कमांडच्या मध्यात सत्र गोठते. बोगदा जोडलेला असल्याचे सांगतो, होस्ट त्यामधून इंटरनेटपर्यंत पोहोचतो, आणि काहीही परत येत नसतानाही तुमचे कीस्ट्रोक येत राहतात. बदललेली गोष्ट बोगदा नाही: तो तुम्हाला पाठवलेल्या पॅकेट्सचा परतीचा मार्ग आहे, जो आता नव्या डीफॉल्ट मार्गाशी जुळतो आणि दूरचा गेटवे तुमच्या टेबलपर्यंत पोहोचण्यासाठी वापरणार नाही अशा बोगद्यात जातो.

redirect-gateway प्रत्यक्षात काय स्थापित करतो

त्याच्या def1 स्वरूपात redirect-gateway डीफॉल्ट मार्ग पुन्हा न लिहिता 0.0.0.0/1 आणि 128.0.0.0/1 जोडतो. हे दोन्ही अर्धे संपूर्ण पत्ता-जागा व्यापतात आणि दोन्ही 0.0.0.0/0 पेक्षा लांब उपसर्ग राहतात, त्यामुळे अधिक विशिष्ट जुळणी नसलेले कोणतेही लक्ष्य आता बोगद्यात जाते. हाच स्मरणात ठेवण्याजोगा यंत्रणा आहे, कारण खालील प्रत्येक दुरुस्ती अधिक विशिष्ट जुळणी स्थापित करून काम करते.

तुमचा प्रशासकीय पत्ता अशा लक्ष्यांपैकी एक आहे.

VPN सर्व्हर त्याच्या क्लायंटचा रहदारी इंटरनेटच्या दिशेने पाठवतो. तुम्ही ज्या सार्वजनिक पत्त्यावरून जोडता त्यासाठी त्याला मार्ग नाही, आणि त्या पॅकेट्सना क्लायंटकडून येणाऱ्या रहदारीपेक्षा वेगळे मानण्याचे कारणही नाही, म्हणून तो ती टाकून देतो. दरम्यान तुम्ही पाठवलेली विनंती होस्टपर्यंत पोहोचली, आणि म्हणूनच सत्र फक्त एका बाजूने जिवंत दिसते.

ip route show table main | head -n 20
ip route get 198.51.100.23

तुमचा स्रोत पत्ता आणि बोगद्यापूर्वीचा मार्ग शोधा

सर्व्हरवर स्थापित SSH कनेक्शनची यादी करा आणि ते ज्या पीअर पत्त्यावरून आले तो नोंदवा. तोच पत्ता तुमच्या परतीच्या मार्गाने व्यापला पाहिजे, आणि तो नेहमी तुम्ही विचार करता तसा नसतो: जंप होस्ट, NAT गेटवे किंवा ऑपरेटरचा अनुवादक दुसरा स्रोत ठेवू शकतो.

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

दोन्ही मूल्ये आणि इंटरफेसचे नाव एकत्र नोंदवा, कारण तुम्ही जोडणार असलेल्या मार्गाला तिन्ही लागतात. होस्टने आपला वरचा दुवा निवडण्यासाठी धोरण-आधारित राउटिंग नियम वापरला असेल, तर साध्या मार्गाचा अजिबात विचार होणार नाही, आणि ही शक्यता दुरुस्ती बदलते.

अर्ध-डीफॉल्टना मागे टाकणारा होस्ट मार्ग पिन करा

एक /32 मार्ग दोन्ही अर्ध-डीफॉल्टपैकी कोणत्याही पेक्षा लांब आहे, त्यामुळे तुमच्या पत्त्यावर येणारी उत्तरे बोगद्याऐवजी तो घेतात. पुढील हॉप बोगद्यापूर्वीचा गेटवे आहे आणि उपकरण भौतिक इंटरफेस आहे, जे पॅकेटला बोगदा अस्तित्वात येण्यापूर्वीच्या मार्गावर ठेवते.

ip route add 198.51.100.23/32 via 203.0.113.1 dev eth0

तक्ता पाहण्याऐवजी लुकअपने तपासा: उत्तरात eth0 आणि गेटवेचे नाव असले पाहिजे, कधीही tun0 नाही.

OpenVPN आधीच VPN सर्व्हरच्या स्वतःच्या पत्त्याकडे होस्ट मार्ग त्याच कारणाने जोडतो, त्यामुळे नमुना परिचित आहे आणि प्रशासकीय पत्ता फक्त अजून एक अपवाद आहे. हे दुरुस्त करण्यासाठी route-nopull कडे जाऊ नका, कारण तो बोगद्याला लागणारे ढकललेले मार्ग टाकून देतो, त्यात दूरचे नेटवर्क आणि DNS पर्यायांचाही समावेश आहे.

ते पुन्हा कनेक्ट होण्यात टिकून राहील असे करा

हाताने जोडलेला मार्ग क्लायंट पुन्हा जोडल्यावर आणि स्वतःचा स्थापित केल्यावर नाहीसा होतो, जे दुरुस्तीला वारंवार होणाऱ्या खंडात बदलते. आदेश मार्ग स्थापित झाल्यानंतर चालणाऱ्या कशाशी जोडा.

एक route-up स्क्रिप्ट आणि नेटवर्क मॅनेजरचा pre-up हुक दोन्ही काम करतात, आणि विश्वासार्ह तपासणी म्हणजे पुन्हा कनेक्ट होऊन तोच लुकअप.

Windows वर समतुल्य म्हणजे -p ने जोडलेला कायमस्वरूपी मार्ग, जो रीबूटमध्ये टिकतो पण नेटवर्क बदलल्यावरही योग्य गेटवेकडे निर्देश करावा लागतो. प्लॅटफॉर्म काहीही असो, मार्गाच्या शेजारी कारण लिहा: पुढील प्रशासकाला हे माहीत असले पाहिजे की तो व्यवस्थापन सत्राच्या संरक्षणासाठी आहे, नेटवर्क डिझाइनने सांगितल्यामुळे नाही.

जेव्हा पिन केलेला मार्गही पुरत नाही

रिव्हर्स-पाथ फिल्टरिंग एका इंटरफेसवर येऊन दुसऱ्यातून जाणारा पॅकेट टाकून देऊ शकते, आणि पिन केलेला मार्ग नेमके तेच तयार करतो. काहीही जागतिक पातळीवर बंद करण्यापूर्वी rp_filter चे प्रभावी मूल्य तपासा, आणि तपासणी बंद करण्यापेक्षा असममिती दुरुस्त करण्यास प्राधान्य द्या. प्रत्येक इंटरफेसची सेटिंग लागू होते, आणि loose मोड बहुतेक वेळा पॅकेट टाकून देण्याऐवजी फक्त असममिती नोंदवतो. फिल्टर तुमची चूक आहे असा निष्कर्ष काढण्यापूर्वी दोन्ही वाचा.

धोरण-आधारित राउटिंग असलेल्या होस्टना मार्गासोबत नियमही लागतो, कारण नियम-आधार आतील मार्गाचा विचार होण्यापूर्वी तक्ता निवडतो. main तक्त्यातील मार्ग दुसऱ्या तक्त्याकडे निर्देश करणाऱ्या नियमाशी जुळणाऱ्या प्रवाहाला अदृश्य असतो. main मध्ये काहीही जोडण्यापूर्वी नियम वाचा. एखादा नियम आधीच व्यवस्थापन रहदारी व्यापत असेल, तर अपवाद त्या नियमाच्या तक्त्यात जातो.

चाचणी करताना बँडबाहेरील कन्सोल उघडे ठेवा, आणि तुम्ही वापरत असलेले लॉगिन तोडण्यापूर्वी दुसऱ्या लॉगिनमधून पुन्हा तपासा. जो मार्ग तुमची स्वतःची व्यवस्थापन रहदारी बोगद्यात पाठवतो तोच तुम्ही दुरुस्त करत असलेले कनेक्शन कापतो. मग परत आत येण्यासाठी सीरियल कन्सोल किंवा रेस्क्यू बूट लागतो, जो एक पडताळणी पायरी वगळण्यासाठी वाईट सौदा आहे.