एक Pi पर दो VPN हॉप: कौन-सा रूट किस पीयर को ले जाता है
एक Pi पर दो टनल पते कोई गड़बड़ी नहीं हैं। हर गंतव्य को अपना वाहक, अपना प्रमाण और बाहरी हॉप मरने पर घोषित बैकअप चाहिए।
एक छोटे बोर्ड पर दो टनल पते गलती जैसे लगते हैं, और प्रतिक्रिया एक को मिटा देने की होती है। वह प्रतिक्रिया उसी चीज़ को तोड़ती है जिसे उसे व्यवस्थित करना था। दो हॉप ले जाने वाला होस्ट हर जोड़ के लिए एक पता रखता है, और हर पता अलग रूट से चुना जाता है। पूछने लायक सवाल यह है कि कौन-सा रूट किस गंतव्य के लिए कौन-सा वाहक चुनता है, यह नहीं कि कितने पते मौजूद हैं।
तीन गंतव्य जिन्हें अलग-अलग वाहक चाहिए
दो हॉप की शृंखला तीन गंतव्य वर्गों की परत है, और हर एक को अलग जोड़ ले जाता है। बाहरी पीयर तक भौतिक लिंक से पहुँचना होता है। भीतरी पीयर तक बाहरी टनल से पहुँचना होता है। ढके हुए ऐप्लिकेशन के गंतव्य तक भीतरी टनल से पहुँचना होता है, जिसका अपना परिवहन बाहरी टनल ले जाती है।
| Destination class | View that names the carrier | Command that proves it | Symptom when the wrong carrier wins |
|---|---|---|---|
| Outer peer, 198.51.100.10 | the main table, by destination | ip route get 198.51.100.10 | the outer handshake never completes |
| Inner peer, 203.0.113.7 | the main table once the outer tunnel is up | ip route get 203.0.113.7 | the inner handshake leaves over the physical link |
| Application destination, 172.30.9.1 | the table the inner client's traffic is selected into | ip route get 172.30.9.1 from 10.8.0.2 | the exit address looks right and the traffic never crossed the outer hop |
| Parallel tunnels, one per source group | one policy per group, not the main table | ip rule show beside a marked test connection | both tunnels are up and one steals the other's traffic |
किसी रूट को छूने से पहले पंक्तियों को पाठक के असली पतों से भरें, क्योंकि तालिका तभी उपयोगी है जब वह ठोस हो। काम करने वाली शृंखला चारों पंक्तियाँ एक साथ पूरी करती है, और आधी काम करने वाली शृंखला आम तौर पर उनमें से एक को गलत वाहक के साथ पूरी करती है। गलत पंक्ति को खराबी के रूप में पढ़ना ही रूटिंग की समस्या को पूरी दोपहर के संपादन में बदल देता है।
पतों की भूमिका होती है, गिनती नहीं
लिनक्स एक इंटरफ़ेस पर कई पते और एक होस्ट पर कई टनल की अनुमति देता है, इसलिए गिनती सही होने के बारे में कुछ नहीं कहती। मायने यह रखता है कि कौन-सा पता किस जोड़ का है, और क्या किसी दिए गए पीयर के लिए रूट वही जोड़ चुनता है जिसका आपने इरादा किया था। तीन दृश्य तीन दिशाओं से इसका उत्तर देते हैं, और उन्हें हर बार उसी क्रम में पढ़ना चाहिए।
पता सूची दिखाती है कि क्या मौजूद है और कौन-सा जोड़ उसका मालिक है। रूट तालिका सामान्य गंतव्य ट्रैफ़िक के लिए वाहक का सवाल जवाब देती है। नीति दृश्य स्रोत या चिह्न से चुने गए ट्रैफ़िक के लिए फिर जवाब देता है, जो दो क्लाइंट एक होस्ट साझा करते समय सामान्य व्यवस्था है।
ip -4 addr show
ip -4 route show table all
ip rule showसूची लंबी लगने के कारण पता मिटाना रास्ते का हिस्सा हटा सकता है, और अतिरिक्त लगने के कारण रूट मिटाना वही काम और चुपचाप करता है। इनमें से कोई त्रुटि नहीं देता; पीयर बस उस रास्ते पर जवाब देना बंद कर देता है जिसका आपने इरादा किया था, जबकि दूसरे रास्ते से पहुँचा हुआ रहता है। भीतरी पीयर का बाहर जाने वाला पता बताने वाला ऐप्लिकेशन यह साबित नहीं करता कि ट्रैफ़िक बाहरी टनल से गुजरा, क्योंकि सीधी पहुँच वही अवलोकन देती है। अवलोकन और प्रमाण के बीच यही खाई रूटिंग परत पर वाहक जाँचने का कारण है।
सक्रियण का क्रम तय इंतज़ार को हराता है
अगर भीतरी क्लाइंट उस पते या रूट पर निर्भर है जो बाहरी क्लाइंट देता है, तो सक्रियण को देरी के बजाय उस संसाधन का इंतज़ार करना चाहिए। इंतज़ार तब तक काम करता है जब तक वह दिन न आए जब बाहरी टनल धीमी हो, और तब यह ऐसे रुक-रुक कर विफल होता है जिसे कोई दोहरा नहीं सकता। निर्भरता पर आधारित क्रम अनुमान हटाता है और निर्भरता को एक बार बताने के अलावा कुछ नहीं लेता। इंटरफ़ेस नाम भी क्रम की व्यवस्था नहीं हैं।
कर्नेल tun0 और tun1 जैसे नाम बनाने के क्रम में देता है, और वह क्रम रीबूट या फिर से जुड़ने के बीच बदल सकता है। कॉन्फ़िगरेशन को उस पहचान से बाँधें जो टूल देता है, या ऐसे नाम से जो आप जानबूझकर देते हैं। आप जो नाम चुनते हैं वह संविदा है; कर्नेल जो नाम चुनता है वह संयोग है।
हर क्लाइंट के परिवहन को दूसरे के ऐप्लिकेशन रूट से बाहर रखें, और इस बारे में सटीक रहें कि OpenVPN 2.6 रूटिंग विकल्प वास्तव में क्या वादा करते हैं। दस्तावेज़ित डिफ़ॉल्ट-रीडायरेक्शन तंत्र क्लाइंट को पहले से मौजूद गेटवे के ज़रिए अपने दूरस्थ पीयर तक पहुँचने में सक्षम रखता है, जो एक विशिष्ट रिकर्शन लूप काटता है। यह एक क्लाइंट को दूसरे का वाहक नहीं बनाता, इसलिए शृंखला का बाकी हिस्सा आपका डिज़ाइन ही रहता है। जहाँ शृंखला को रूट के बजाय नीति चाहिए, वहाँ स्पष्ट स्रोत या चिह्न नियम लिखें और उसे उस ट्रैफ़िक से जाँचें जिससे उसे मेल खाना है।
जब बाहरी हॉप मरता है तो क्या होता है
शृंखला के पूरा माने जाने से पहले तय करें कि बाहरी हॉप गायब होने पर क्या होगा। भीतरी क्लाइंट का परिवहन उसके साथ मर जाता है, और अगला कदम तकनीकी नहीं बल्कि नीति का सवाल है: विफल होना, फिर कोशिश करना, या भौतिक लिंक से सीधे फिर जुड़ना। तीसरा परिणाम ही सोचने लायक है। जिस पल उपयोगकर्ता मानता है कि कवरेज अब भी बरकरार है, उसी पल यह चुपचाप दो-हॉप डिज़ाइन को एक-हॉप डिज़ाइन में बदल देता है।
अगर दो हॉप अनिवार्य हैं, तो बाहरी के जाने पर भीतरी क्लाइंट सीधा रास्ता स्थापित नहीं कर पाना चाहिए, और यह जानने का तरीका बाहरी हॉप को तोड़कर देखना है कि भीतरी क्या करता है। मंज़ूर बैकअप वैध उत्तर है, लेकिन उसे लिखा, जाँचा और बताया जाना चाहिए। जिस बैकअप को किसी ने दस्तावेज़ नहीं किया वह किसी घटना की समीक्षा में लीक से अलग नहीं पहचाना जा सकता।
DNS और दूसरा पता परिवार उसी फैसले का हिस्सा हैं। स्थानीय रूप से बनी क्वेरी होस्ट की अपनी नीति का पालन करती है, फ़ॉरवर्ड किए गए क्लाइंट की नहीं, इसलिए फ़ॉरवर्ड ट्रैफ़िक के लिए काम करने वाला रिज़ॉल्वर वह नहीं हो सकता जो होस्ट खुद इस्तेमाल करता है।
हर परत को उसी क्रम में स्वीकारें जिसमें आपने उसे बनाया
उसी क्रम में जाँचें जिसमें शृंखला बनी: पहले अकेली बाहरी टनल, फिर बाहरी टनल से भीतरी क्लाइंट का परिवहन, फिर भीतरी टनल से ऐप्लिकेशन। हर स्वीकृति नया कनेक्शन होनी चाहिए, पहले से खुला पेज नहीं। फिर हर परत को अलग-अलग तोड़ें और बहाल करें और देखें कि अगली क्या करती है।
बैकअप का परिणाम यहाँ सबसे मूल्यवान अवलोकन है, और वह जो सार्वजनिक IP पेज कभी नहीं दिखाता। पीयर के रास्ते, उनके इस्तेमाल किए पते और वह परिणाम कॉन्फ़िगरेशन के पास सहेजें, क्योंकि खुशहाल रास्ता वह हिस्सा नहीं है जिस पर बाद में सवाल उठता है।