दुसरी VPN बोगदा पहिली का तोडते?

एका ग्राहक नेटवर्कपर्यंत पोहोचण्यासाठी दुसरा VPN क्लायंट स्थापित करणे हा याचा नेहमीचा प्रारंभ असतो, आणि दोन्ही क्लायंट यश नोंदवत असतानाच पहिली बोगदा अंधारी होते। प्रत्येक क्लायंटने डीफॉल्ट मार्ग स्थापित केला, दुसरा अधिक विशिष्ट होता, आणि कर्नेल आता पहिल्या बोगद्याच्या स्वतःच्या बाह्य जोडणीशिवाय सर्वासाठी तोच अनुसरतो। काहीही कोसळले नाही आणि कोणतेही प्रोफाइल चुकीचे नाही। एका मार्गाने दुसऱ्याची जागा घेतली, आणि उपाय म्हणजे कोणत्या बोगद्याकडे डीफॉल्ट असावा हे ठरवणे।

लक्षण: दुसरा क्लायंट शांतपणे जिंकतो

OpenVPN: redirect-gateway def1 पर्याय 0.0.0.0/0 ला पुनर्लेखित करत नाही। तो 0.0.0.0/1 आणि 128.0.0.0/1 जोडतो: दोन्ही मिळून प्रत्येक IPv4 पत्ता व्यापतात, आणि प्रत्येक प्रीफिक्स लांबीने साध्या डीफॉल्टला हरवतो। मूळ डीफॉल्ट टेबलमध्ये राहते आणि सामान्य रहदारीसाठी वापरले जाणे थांबते, आणि VPN सर्व्हरकडे जाणारा होस्ट मार्ग बोगद्याला स्वतःचे बाह्य पॅकेट पकडण्यापासून रोखतो। दोन्ही क्लायंट हे करतात, आणि दुसरा फक्त आपली जोडी नंतर स्थापित करतो।

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

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

कोणती बोगदा प्रत्यक्षात जिंकते ते वाचा

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

ip route show
ip route get 198.51.100.24
route print -4
Find-NetRoute -RemoteIPAddress 198.51.100.24

पहिले दोन Linux चे उत्तर आणि शेवटचे दोन Windows चे समतुल्य। दोन्ही बोगदे वर असताना ते चालवा, नंतर एक बंद करा आणि पुन्हा चालवा। दोन्ही आउटपुटमधील फरक हीच उपाय निवडण्यापूर्वी आवश्यक असलेली वस्तुस्थिती आहे, आणि तो कोणत्याही क्लायंटचा लॉग वाचण्यापेक्षा कमी वेळ घेतो।

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

Windows: एका प्रोफाइलला डीफॉल्टचे मालकी घेण्यापासून रोखा

Windows साठवलेली प्रोफाइल्स ठेवते, आणि अंगभूत क्लायंट एकाला दुसऱ्यावर अवलंबून राहू देतो जेणेकरून दुसरा जोडला की पहिला स्वयंचलितपणे वर येतो। सर्वात शेवटी जोडलेले प्रोफाइल डीफॉल्ट ठेवण्याची प्रवृत्ती दाखवते, म्हणून व्यावहारिक मालक पहिला नाही तर शेवटचा डायल आहे। प्रत्येक प्रोफाइलला स्वतःचे push मार्ग द्या आणि ज्याला डीफॉल्ट नसावा त्यासाठी स्प्लिट बोगदा चालू करा।

Set-VpnConnection -Name "Contoso" -SplitTunneling $true
rasdial Contoso

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

ॲप-ट्रिगर प्रोफाइल्स हे वेगळे वैशिष्ट्य आहे आणि जाणून घेण्यासारखे आहे: Windows प्रोफाइल नामांकित एक्झिक्युटेबल सुरू झाल्यावर सुरू होऊ शकते, ज्यात रहदारी फिल्टर काय वाहील ते ठरवतात। हे फायरवॉल नियम नाही तर प्रोफाइल सेटिंग आहे, आणि ते डीफॉल्ट-मार्ग संघर्षापेक्षा वेगळी समस्या सोडवते।

Linux: दुसरी बोगदा मुख्य टेबलबाहेर ठेवा

एका मशीनवर openvpn --config च्या दोन प्रतिकृती चालवल्यास दोन्ही क्लायंट एकाच टेबलमध्ये येतात, आणि तीन पर्याय वाढत्या अलगावाने त्यांना वेगळे करतात। सर्वात हलका म्हणजे दुसऱ्या क्लायंटला टेबल अजिबात संपादित करू न देणे: स्पष्ट मार्गांसह route-nopull, किंवा तुम्ही हेतू असलेलेच स्थापित करणारी route-up स्क्रिप्ट। मग दुसरी बोगदा तुम्ही नामनिर्देशित केलेले प्रीफिक्सच वाहते आणि इतर काहीही नाही। मग नंतर शोधण्याऐवजी कोणते प्रीफिक्स कुठे जाईल हे स्वतः ठरवता।

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

ip rule add from 10.44.7.0/24 table 100
ip route add default dev tun1 table 100
sysctl net.ipv4.conf.all.rp_filter

नेटवर्क नेमस्पेस हा सर्वात जड आणि सर्वात स्वच्छ पर्याय आहे। दुसरा क्लायंट ip netns च्या आत सुरू करा, त्याला veth जोडी द्या, आणि वापरण्यासाठी त्या नेमस्पेसमध्ये प्रवेश करा। हस्तक्षेप नाहीशा होतो कारण प्रत्येक नेमस्पेस एक टेबल सामायिक करण्याऐवजी स्वतःची टेबल ठेवतो, जे दोन्ही बोगदे आठवड्यांनुसार वर ठेवावे लागल्यास त्या अतिरिक्त सेटअपला योग्य आहे।

प्रति-अनुप्रयोग, आणि साखळी वेगळी समस्या म्हणून

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

साखळी करणे हे दोन बोगदे शेजारी चालवण्यापेक्षा वेगळे ऑपरेशन आहे। A ला B वरून साखळणे म्हणजे आतील सर्व्हरचा पत्ता बाह्य बोगद्याच्या आतून पोहोचण्यायोग्य असला पाहिजे। बाह्य क्लायंटनेही आतील क्लायंटचे गुप्तपॅकेट गळती समजू नयेत। व्हर्च्युअल मशीनमधील एक क्लायंट ही ओबडधोबड पण विश्वासार्ह आवृत्ती आहे; दोन्ही एकाच होस्टवर असल्यास वरील राउटिंग काम आणि आतील सर्व्हरकडे जाणारा असा बाह्य मार्ग लागतो जो कधीही आतील बोगद्यात प्रवेश करत नाही।

डीफॉल्टचा मालक, प्रत्येक बोगदा वाहणाऱ्या प्रीफिक्सची यादी आणि DNS मार्ग लिहून ठेवा। त्या तीन वस्तुस्थिती पुढील घटनेला तपासणीऐवजी शोधात बदलतात।