OpenVPN चा फुल टनेल तुमचे SSH सत्र तोडतो: परतीचा मार्ग दुरुस्त करा

SSH ने पोहोचता अशा मशीनवर फुल-टनेल OpenVPN क्लायंट सुरू केल्यास सत्र एका सेकंदात तुटू शकते, आणि मशीन काहीही चुकीचे करत नाही। टनेल पॅकेट सर्व्हरपर्यंत कसे पोहोचतात हे बदलत नाही; उत्तरे कशी बाहेर पडतात ते बदलते। डीफॉल्ट रूट tun0 कडे निर्देश करताच, तुमच्या SSH क्लायंटला जाणारे उत्तर प्रदात्याच्या नेटवर्कमध्ये जाते, ज्याला तुमच्या पत्त्याकडे परत जाण्याचा कोणताही मार्ग नाही। कनेक्शन लटकते, पुढील प्रयत्न वेळ संपून अयशस्वी होतो, आणि डेमन संपूर्ण वेळ पोर्ट 22 वर ऐकत असतो।

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

उत्तर चुकीच्या दारातून का बाहेर पडते

येणारे पॅकेट अजूनही भौतिक इंटरफेसवर येतात, कारण VPN क्लायंट इंटरनेट तुमच्या सर्व्हरच्या सार्वजनिक पत्त्यापर्यंत कसे पोहोचते हे बदलू शकत नाही। उत्तरे हा वेगळा निर्णय आहे: प्रत्येक पॅकेटसाठी कर्नेल गंतव्य शोधते, आणि --redirect-gateway नंतर डीफॉल्ट नोंद टनेल असे म्हणते। प्रदात्याचे एक्झिट आपण सेवा देत नसलेले गंतव्य पाहते आणि पॅकेट टाकून देते।

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

एक प्रीफिक्स चूक लवकर वगळण्यासारखी आहे। लांबीशिवाय ip route add -net 0.0.0.0 gw 10.8.0.1 dev tun0 फक्त एका 0.0.0.0 पत्त्याशी जुळते, इंटरनेटशी नाही; ते 0.0.0.0/0 असावे। आणि जर डीफॉल्ट घेतल्याने टनेलची स्वतःची वाहतूक तुटत असेल, तर भौतिक इंटरफेसमार्फत एंडपॉइंट होस्ट रूट म्हणून जोडा, प्रदात्याचा खरा पत्ता वापरून।

तात्काळ दुरुस्तीसाठी तुमच्या SSH क्लायंटचा पत्ता पिन करा

सर्वात वेगवान दुरुस्ती म्हणजे टनेल येण्यापूर्वी सर्व्हरने वापरलेल्या गेटवेमार्फत तुमच्या क्लायंट पत्त्यासाठी होस्ट रूट। तुमच्या बाजूने सर्व्हर जो पत्ता पाहील तो शोधा, नंतर जुना गेटवे जाणून घेण्यासाठी सर्व्हरचे टेबल वाचा:

curl -s https://ifconfig.co
ip route

सर्व्हरवर, क्लायंट सुरू होण्यापूर्वी अपवाद जोडा। येथील पत्ते प्लेसहोल्डर आहेत; आकार महत्त्वाचा आहे:

sudo ip route add 80.128.240.55 via 192.168.178.1

ही नोंदवलेल्या प्रकरणात वापरलेली दुरुस्ती आहे, आणि ती लगेच काम करते। ती दोन अंदाजे मार्गांनी नाजूकही आहे: रीबूटमध्ये रूट नाहीशी होते, आणि तुमचा ISP दुसरा पत्ता देतो त्या क्षणी ती चुकीची होते। तिला आपत्कालीन उपाय माना आणि जाणीवपूर्वक टिकाऊ करा, नेटवर्क युनिट किंवा डिस्पॅचर हुकद्वारे, किंवा ती तात्पुरती आहे हे मान्य करून पुनर्प्राप्तीचा मार्ग लिहून ठेवा।

क्लायंटला डीफॉल्ट घेऊ देऊ नका

अधिक स्वच्छ पर्याय म्हणजे टनेलला डीफॉल्ट रूट अजिबात बदलू न देणे। route-nopull, --client किंवा --pull सोबत वापरल्यास, रूट, block-outside-dns आणि DNS सर्व्हरसारखे DHCP शैलीचे पर्याय सोडून ढकललेले पर्याय स्वीकारते, त्यामुळे तुम्ही फक्त आवश्यक प्रीफिक्स जोडता। अधिक अरुंद साधन म्हणजे पुल फिल्टर, जे एक अडचणीची सूचना टाकून देते आणि उर्वरित ठेवते:

route-nopull
pull-filter ignore "redirect-gateway"

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

परतीचा मार्ग स्रोत किंवा कनेक्शननुसार विभागा

येणारा पत्ता स्थिर असल्यास, स्रोत नियम टनेलच्या स्वतःच्या रूटला स्पर्श न करता उत्तरे स्थानिक ठेवतो। भौतिक इंटरफेसच्या पत्त्याला LAN प्रीफिक्स आणि भौतिक डीफॉल्ट असलेले स्वतःचे टेबल द्या, नंतर तेथून येणाऱ्या रहदारीसाठी तेच टेबल निवडा:

ip rule add from 192.168.1.11 table 128
ip route add table 128 to 192.168.1.0/24 dev eth0
ip route add table 128 default via 192.168.1.1

हे काम करते कारण येणाऱ्या SSH कनेक्शनची उत्तरे क्लायंट ज्या पत्त्यावर जोडला होता त्याच पत्त्यावरून जातात। ज्या नोंदवलेल्या प्रकरणात प्रत्येक येणाऱ्या सेवेला चालू राहायचे होते, तेथे नेमका हाच आकार वापरला गेला। येणारा पत्ता तरंगत असेल किंवा मार्ग गतिशील असेल, तर त्याऐवजी कनेक्शन चिन्हांकित करा: भौतिक इंटरफेसवरून येणाऱ्या पहिल्या पॅकेटवर conntrack चिन्ह लावा, OUTPUT मध्ये उत्तर पॅकेटवर त्याची प्रत करा, आणि चिन्हांकित पॅकेट भौतिक गेटवेकडे निर्देश करणाऱ्या टेबलमार्फत रूट करा।

iptables -t mangle -A PREROUTING -i eth0 -m conntrack --ctstate NEW -j CONNMARK --set-mark 1234
iptables -t mangle -A OUTPUT -m connmark --mark 1234 -j MARK --set-mark 4321
ip route add default via 192.168.1.1 dev eth0 table 3412
ip rule add fwmark 4321 table 3412

चाचणी करताना कनेक्शन चिन्ह, फायरवॉल चिन्ह आणि टेबल क्रमांक वेगळे ठेवा। दोन भूमिकांसाठी एकच क्रमांक पुन्हा वापरल्यास बरोबर दिसणारा आणि चुकीच्या पॅकेटशी जुळणारा नियम तयार होतो। टेबलच्या डीफॉल्ट नोंदीला सामान्य इथरनेट लिंकवर LAN गेटवेसह via देखील आवश्यक आहे; उघडा dev eth0 फक्त तेव्हाच काम करतो जेव्हा इंटरफेस पॉइंट-टू-पॉइंट असेल किंवा पुढील हॉप दुसऱ्या मार्गाने सुटत असेल। नोंदवलेला Jessie होस्ट नक्कीच उघड्या स्वरूपाने चालणाऱ्या लिंकवर होता, जो नकल करण्यासारखा कोणताही वितरण नियम नाही।

स्वतःला बाहेर कुलूपबंद न करता तपासा

डिस्कनेक्ट करून चाचणी करू नका। पहिले सत्र उघडे ठेवा, टनेल वर आणा, आणि कर्नेलला विचारा की तुमचा स्वतःचा पत्ता कोणता मार्ग घेईल:

ip route get 80.128.240.55

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

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