एका Pi वर दोन VPN हॉप: कोणता रूट कोणत्या पीअरला नेतो

एका लहान बोर्डवर दोन टनेल पत्ते चूक वाटतात, आणि प्रतिक्रिया एक पुसून टाकण्याची असते। ती प्रतिक्रिया जे व्यवस्थित करायचे होते तेच तोडते। दोन हॉप वाहणारा होस्ट प्रत्येक जोडणीसाठी एक पत्ता ठेवतो, आणि प्रत्येक पत्ता वेगळ्या रूटने निवडला जातो। विचारण्यासारखा प्रश्न असा आहे की कोणता रूट कोणत्या गंतव्यासाठी कोणता वाहक निवडतो, किती पत्ते आहेत हा नाही।

वेगवेगळे वाहक आवश्यक असलेली तीन गंतव्ये

दोन हॉपची साखळी म्हणजे एकावर एक रचलेले तीन गंतव्य वर्ग, आणि प्रत्येकाला वेगळी जोडणी वाहते। बाहेरील पीअरपर्यंत भौतिक दुव्याने पोहोचावे लागते। आतील पीअरपर्यंत बाहेरील टनेलने पोहोचावे लागते। झाकलेल्या ॲप्लिकेशनच्या गंतव्यापर्यंत आतील टनेलने पोहोचावे लागते, ज्याची स्वतःची वाहतूक बाहेरील टनेल वाहते।

रूटला हात लावण्यापूर्वी ओळी वाचकाच्या खऱ्या पत्त्यांनी भरा, कारण तक्ता ठोस असेल तेव्हाच उपयुक्त ठरतो। कार्यरत साखळी चारही ओळी एकाच वेळी पूर्ण करते, आणि अर्धवट कार्यरत साखळी सहसा त्यापैकी एक चुकीच्या वाहकाने पूर्ण करते। चुकीची ओळ दोष म्हणून वाचणे हेच रूटिंगच्या समस्येचे पूर्ण दुपारच्या दुरुस्त्यांमध्ये रूपांतर करते।

पत्त्यांना संख्या नाही, भूमिका असतात

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

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

ip -4 addr show
ip -4 route show table all
ip rule show

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

सक्रियतेचा क्रम ठराविक वाट पाहण्यावर मात करतो

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

कर्नल tun0 आणि tun1 सारखी नावे निर्मितीच्या क्रमाने देतो, आणि तो क्रम पुन्हा सुरू करणे किंवा पुन्हा जोडणे यांमध्ये बदलू शकतो। संरचना साधन देत असलेल्या ओळखीशी किंवा तुम्ही जाणीवपूर्वक दिलेल्या नावाशी जोडा। तुम्ही निवडलेले नाव करार आहे; कर्नल निवडलेले नाव योगायोग आहे।

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

बाहेरील हॉप मेल्यावर काय होते

साखळी पूर्ण मानण्यापूर्वी बाहेरील हॉप अदृश्य झाल्यावर काय होईल ते ठरवा। आतील क्लायंटची वाहतूक त्यासोबत मरते, आणि पुढचे पाऊल तांत्रिक नसून धोरणाचा प्रश्न आहे: अयशस्वी होणे, पुन्हा प्रयत्न करणे, किंवा भौतिक दुव्याने थेट पुन्हा जोडणे। तिसरेच परिणाम विचार करण्यासारखे आहे। वापरकर्ता कव्हरेज अजून अभंग आहे असे मानत असतानाच तो क्षण येतो आणि ते दोन हॉपच्या रचनेचे एका हॉपच्या रचनेत शांतपणे रूपांतर करते।

दोन हॉप अनिवार्य असतील, तर बाहेरील गेल्यावर आतील क्लायंटला थेट मार्ग स्थापित करता येऊ नये, आणि हे जाणून घेण्याचा मार्ग म्हणजे बाहेरील हॉप तोडून आतील काय करते ते पाहणे। मंजूर पर्यायी मार्ग हे वैध उत्तर आहे, पण ते लिहिले, चाचणी केलेले आणि सांगितले पाहिजे। कोणीही दस्तऐवज न केलेला पर्यायी मार्ग घटना पुनरावलोकनात गळतीपासून वेगळा ओळखता येत नाही।

DNS आणि दुसरे पत्ता कुटुंब त्याच निर्णयाचा भाग आहेत। स्थानिक पातळीवर तयार केलेला शोध फॉरवर्ड केलेल्या क्लायंटचे धोरण नाही तर होस्टचे स्वतःचे धोरण अनुसरतो, त्यामुळे फॉरवर्ड वाहतुकीसाठी चालणारा रिझॉल्व्हर होस्ट स्वतः वापरत असलेला असेलच असे नाही।

प्रत्येक स्तर तुम्ही बनवलेल्या क्रमाने स्वीकारा

साखळी ज्या क्रमाने बांधली गेली त्या क्रमाने चाचणी करा: आधी एकटा बाहेरील टनेल, नंतर बाहेरील टनेलमधून आतील क्लायंटची वाहतूक, नंतर आतील टनेलमधून ॲप्लिकेशन। प्रत्येक स्वीकृती आधीच उघडलेले पान नसून नवीन जोडणी असावी। नंतर प्रत्येक स्तर स्वतंत्रपणे तोडा आणि पुनर्संचयित करा आणि पुढचा काय करतो ते पाहा।

पर्यायी मार्गाचा निकाल हा येथे सर्वात मौल्यवान निरीक्षण आहे, आणि सार्वजनिक IP पान कधीही दाखवत नाही तो। पीअरचे मार्ग, ते वापरत असलेले पत्ते आणि तो निकाल संरचनेच्या शेजारी जतन करा, कारण आनंददायी मार्ग हा नंतर प्रश्नार्थ निघणारा भाग नाही।