VPN वरून Dante SOCKS: पूर्ण टनल विरुद्ध स्रोत-आधारित राउटिंग

तुम्हाला SOCKS प्रॉक्सीचा रहदारी VPN मधून बाहेर जावा आणि उर्वरित होस्टने आपला नेहमीचा मार्ग ठेवावा असे वाटते. दोन रचना हे करतात, आणि काही चूक झाल्यास काय तुटते यात त्या वेगळ्या आहेत. एक टनलमध्ये डीफॉल्ट रूट ढकलते आणि नंतर त्याला वळसा घालते; दुसरी मुख्य तक्त्याला अक्षय ठेवते आणि एक स्रोत पत्ता दुसऱ्या तक्त्याकडे पाठवते. दुसरी अधिक स्वच्छ आहे, आणि तिचे स्वतःचे सापळे आहेत.

दोन रचना, दोन वेगळ्या हानीच्या त्रिज्या

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

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

ही अरुंदता हीच मर्यादा आहे: प्रॉक्सीचे बाहेर जाणारे पॅकेट खरोखर तो पत्ता वाहत असतील तरच रचना काम करते.

Dante ची external सेटिंग काय करते

external सेटिंग प्रॉक्सी बाहेर जाणाऱ्या जोडण्यांसाठी वापरत असलेले पत्ते निवडते; ती कर्नेलच्या राउटिंग धोरणाला स्पर्श करत नाही. हेच विभाजन दुसरी रचना शक्य करते, आणि इथेच लोक दस्तऐवज चुकीचे वाचतात. external टनलच्या पत्त्याकडे वळवल्यास प्रॉक्सी आपली जोडणी त्या पत्त्यावरून निर्माण करते, आणि नंतर राउटिंग तक्ता ते पॅकेट कुठे जातात हे ठरवतो.

श्रोता ही वेगळी बाब आहे. internal फक्त ज्या क्लायंटनी प्रॉक्सी वापरावी त्यांच्यापुरता मर्यादित ठेवा, प्रमाणीकरण आवश्यक करा आणि पोर्ट फायरवॉलने बंद करा, कारण उघडा श्रोता VPN निर्गमाचे वैशिष्ट्य नाही.

कॉन्फिगर केलेला पत्ता प्रॉक्सीच्या नेटवर्क नामस्थानात खरोखर टनलचा आहे याची खात्री करा.

स्रोत-निवड तक्ता तयार करणे

10.90.0.2/24 TUN पत्ता, 10.90.0.1 वर पोहोचण्यायोग्य पीअर, आणि दुसरे काहीही वापरत नसलेला तक्ता क्रमांक असेल तर मांडणी अशी दिसते:

ip -4 route add table 100 10.90.0.0/24 dev tun0 src 10.90.0.2
ip -4 route add table 100 default via 10.90.0.1 dev tun0 metric 10
ip -4 route add table 100 unreachable default metric 32760
ip -4 rule add priority 1000 from 10.90.0.2/32 lookup 100

अगम्य रूट हा लोक वगळतात तो भाग. त्याशिवाय, ज्या तक्त्याचा टनल रूट नाहीसा होतो तो नेहमीच्या डीफॉल्टवर पडतो आणि प्रॉक्सी शांतपणे WAN मधून बाहेर पडते. त्यासह, शोध अयशस्वी होतो, जो शांत गळतीऐवजी दृश्यमान अपयश आहे. नियमाची प्राधान्यक्रमही त्या स्रोताशी जुळणाऱ्या इतर सर्वांपेक्षा आधी असावा.

ही मूल्ये एक टोपोलॉजी वर्णन करतात. पॉइंट-टू-पॉइंट पीअर, net30 अॅड्रेसिंग आणि वेगळा प्रीफिक्स देणारे क्लायंट या सर्वांना स्वतःचे रूट लागतात, म्हणून पत्ते नाही, आकार कॉपी करा.

स्रोत नियम कुठे गळतो

स्रोत पत्त्याशी जुळणारा नियम तो वापरणाऱ्या प्रत्येक प्रक्रियेवर परिणाम करतो, केवळ प्रॉक्सीवर नाही. दुसरा डीमन तोच पत्ता बांधत असेल, तर त्याचाही रहदारी टनल घेतो, आणि अपयश असंबंधित सेवेच्या समस्येसारखे दिसेल. प्रॉक्सीला दुसरे कोणीही न वापरणारा पत्ता द्या, किंवा व्याप्ती प्रक्रिया नाही, पत्ता आहे हे मान्य करा.

DNS ही दुसरी गळती. रिझॉल्व्हर सॉकेट प्रॉक्सीच्या external डेटा-जोडणीचा स्रोत वापरतोच असे नाही, त्यामुळे नाव शोध अजूनही WAN मधून बाहेर जाऊ शकतो. जोडणी स्थापन करण्यापासून वेगळे रिझोल्यूशन तपासा, आणि तो निकाल स्वीकारार्ह आहे का ते ठरवा.

IPv6 ला स्वतःचे नियम आणि रूट लागतात, कारण IPv4 ची मांडणी त्याबद्दल काहीही सिद्ध करत नाही.

तुम्ही सहन करू शकता त्या अपयशानुसार निवडा

होस्टचे संपूर्ण संरक्षण करायचे असेल आणि वगळण्याची यादी सांभाळता येत असेल तर पूर्ण टनल निवडा. होस्टने स्वतःचा मार्ग ठेवायचा असेल आणि फक्त एक सेवा वळवायची असेल तर स्रोत-आधारित राउटिंग निवडा. दोन्ही वैध आहेत; चूक म्हणजे एक निवडून नंतर ती दुसरी असल्यासारखी तपासणे.

कोणतेही निवडा, दोन्ही बाजूंनी पडताळा: प्रॉक्सीमधून एक विनंती आणि होस्टकडून थेट विनंती, प्रत्येकासाठी आढळलेला निर्गम पत्ता नोंदवून.

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