जब VPN राउटर पर चलता है तो STUN उत्तर क्या प्रकट करता है
राउटर का टनल पता ब्राउज़र का स्थानीय पता नहीं है। रिफ्लेक्टर क्या बताता है यह पढ़ने से पहले यह देखें कि हर अनुरोध कैसे रूट और अनुवादित होता है।
जब टनल राउटर पर रहता है, तो ब्राउज़र चलाने वाली मशीन में कोई टनल इंटरफ़ेस ही नहीं होता। उस मशीन से उसके स्थानीय पते पूछें और आपको एक निजी LAN पता और एक लूपबैक मिलेगा, VPN पते जैसा कुछ नहीं। फिर भी दूसरी ओर का STUN सर्वर पथ के बारे में कुछ सार्थक बता सकता है, और वह क्या बताता है यह पूरी तरह इस पर निर्भर है कि वह विशेष अनुरोध कैसे रूट और अनुवादित हुआ।
यही वह हिस्सा है जिस पर धीरे रुकना चाहिए। “ब्राउज़र VPN पते का मालिक नहीं है” इंटरफ़ेस के बारे में एक प्रश्न का उत्तर देता है, जबकि परावर्तित पता अनुवाद से गुज़रने वाले पथ के बारे में उत्तर है। दोनों को मिलाने से प्रकटीकरण के बारे में आत्मविश्वासी निष्कर्ष निकलते हैं जिनका साक्ष्य समर्थन नहीं करता।
दो डिवाइस, इंटरफ़ेस के दो समूह
राउटर-आधारित व्यवस्था में टनल राउटर पर समाप्त होता है और LAN क्लाइंट सामान्य ट्रैफ़िक अपने डिफ़ॉल्ट गेटवे को भेजता है। क्लाइंट की इंटरफ़ेस सूची छोटी रहती है: एक निजी पता, शायद दूसरे नेटवर्क के लिए दूसरा, और लूपबैक। जोखिम यह नहीं है कि इनमें से कोई संयोग से टनल पता हो; जोखिम यह है कि अनुरोध उस पथ से निकले जिसे आपने नहीं चुना।
क्लाइंट से पूछें कोई विशिष्ट गंतव्य कौन-सा मार्ग लेगा, यह पूछने के बजाय कि कौन-से इंटरफ़ेस मौजूद हैं। उत्तर एक गेटवे और वह स्रोत पता बताता है जो कर्नेल उपयोग करेगा, और यह किसी भी पता-सूची से अधिक जानकारीपूर्ण है।
ip route get 198.51.100.20
ip -6 route get 2001:db8::20
wg show wg0 allowed-ipsदस्तावेज़ीकरण श्रेणियाँ परीक्षण के लिए अच्छे गंतव्य हैं क्योंकि वे कभी किसी वास्तविक सेवा में हल नहीं होतीं। क्लाइंट जो कहता है उसकी राउटर जो कहता है उससे तुलना करें, और किसी भी अंतर को इस बात का प्रमाण मानें कि नीति रूटिंग, स्प्लिट-टनल नियम या दूसरा डिफ़ॉल्ट मार्ग कुछ ऐसा कर रहा है जिसका आपने हिसाब नहीं रखा।
Binding उत्तर क्या कह सकता है
RFC 8489 Binding अनुरोध और प्रतिक्रिया को परिभाषित करता है, जिसमें सर्वर उस अनुरोध के लिए देखा गया स्रोत परिवहन पता बताता है। यह एक क्षण में एक पंचक के बारे में कथन है, क्लाइंट के इंटरफ़ेस की गणना नहीं। इसलिए रोचक सब कुछ क्लाइंट और अवलोकन बिंदु के बीच होता है।
उस अंतराल को रूटिंग और अनुवाद भरते हैं। जो राउटर बाहर जाते ट्रैफ़िक पर स्रोत NAT करता है वह क्लाइंट के निजी स्रोत को बाहर जाते इंटरफ़ेस पर अपने पते से बदल देता है। यदि वह इंटरफ़ेस टनल है, तो रिफ्लेक्टर टनल पता देखता है। यदि पैकेट टनल से बाहर रखा गया था, तो रिफ्लेक्टर वह देखता है जो WAN अनुवाद ने बनाया। वही क्लाइंट, वही रिफ्लेक्टर, अलग उत्तर।
तीन स्थितियाँ जो एक जैसी दिखती हैं और हैं नहीं
उपयोगी भेद सार्वजनिक बनाम निजी नहीं है, बल्कि यह है कि किस प्रवर्तन बिंदु ने पैकेट संभाला। स्थितियों को राउटर की अपनी तालिकाओं के साथ खुली रखकर देखें, क्योंकि एक ही ब्राउज़र तीनों पैदा कर सकता है, उस नियम के अनुसार जिसे लिखना आप भूल गए।
| Where the request leaves | What rewrites the source | What the reflector reports |
|---|---|---|
| Tunnel interface on the router | Router NAT towards the tunnel address | The tunnel address as seen on that path |
| WAN interface, excluded by policy | Ordinary WAN translation | The public WAN address |
| Private reflector reached through the tunnel route | Router NAT towards the tunnel address | An internal identifier valid only inside that path |
केवल दूसरी स्थिति ही उस शर्त का उल्लंघन करती है कि कुछ ट्रैफ़िक कभी सीधे बाहर न जाए, और केवल पहली और तीसरी ही टनल पक्ष का पहचानकर्ता प्रकट करती हैं। तीनों पंक्तियों में से कोई भी किसी विशेष प्रदाता के व्यवहार के बारे में दावा नहीं है: निजी रिफ्लेक्टर तक पहुँचना संभव है या नहीं, यह रूटिंग, दूसरी ओर के अनुमत IP पतों और दोनों सिरों की फ़ायरवॉल नीति पर निर्भर करता है।
उसी प्रदाता के पास खाता होना इनमें से कुछ भी सिद्ध नहीं करता। यह भी याद रखने योग्य है कि रूट किया गया अनुरोध क्लाइंट का LAN स्रोत बनाए रख सकता है यदि कोई उसका अनुवाद न करे, इसलिए स्रोत फ़ील्ड को टोपोलॉजी आरेख से मानने के बजाय खोजना पड़ता है।
इकट्ठा करना चुनना नहीं है
WebRTC आज़माने के लिए उम्मीदवार पते इकट्ठा करता है, और निदान सूची में दिखने वाला उम्मीदवार कभी मीडिया न भेजे। सूची को “दूसरे पक्ष ने यही सीखा” के रूप में पढ़ना साक्ष्य को बढ़ा-चढ़ाकर पेश करता है। चुना गया युग्म ही वह है जिसने वास्तव में सत्र ढोया, और वह दूसरे फ़ील्ड में रहता है।
HTTPS निकास जाँचकर्ता एक और प्रश्न का उत्तर देता है: वह स्रोत पता जो किसी वेब सर्वर ने उस अनुरोध के लिए देखा। यह उपयोगी क्रॉस-जाँच है क्योंकि यह UDP रिफ्लेक्टर से भिन्न प्रोटोकॉल और अक्सर भिन्न गंतव्य उपयोग करता है, और दोनों के बीच असंगति सामान्यतः बग नहीं बल्कि रूटिंग नियम की ओर संकेत करती है।
नीति तय करें, फिर उत्तर पढ़ें
परीक्षण से पहले इरादा लिखें: कौन-सा ट्रैफ़िक टनल का उपयोग करना चाहिए, कौन-सा सीधे निकल सकता है, कौन-से पता परिवार दायरे में हैं, और टनल बंद होने पर क्या होना चाहिए। उस आधार-रेखा के बिना हर अवलोकन अस्पष्ट है, क्योंकि आप रिसाव को उस मार्ग से अलग नहीं कर सकते जिसे आपने जान-बूझकर अनुमति दी।
फिर एक बार में एक प्रश्न पूछें। यह गंतव्य कौन-सा मार्ग लेता है। यह रिफ्लेक्टर कौन-सा पता बताता है। सत्र ने कौन-सा उम्मीदवार युग्म चुना। उत्तरों को नीति के पास रखें और तारीख लगाएँ, क्योंकि फ़र्मवेयर अद्यतन डिफ़ॉल्ट व्यवहार को ऐसे बदल सकता है जो पिछले साल के निष्कर्ष को चुपचाप अमान्य कर दे।
राउटर अब भी मजबूत प्रवर्तन बिंदु है, क्योंकि यह वह ट्रैफ़िक देखता है जिसे क्लाइंट स्वयं को फिर से विन्यस्त किए बिना टाल नहीं सकता। यह वह वादा नहीं है कि हर अनुप्रयोग प्रोटोकॉल का हर फ़ील्ड कुछ भी प्रकट नहीं करता, और यह उन पथों को लिखने का विकल्प भी नहीं है जिन्हें अनुमति देने का आपने चयन किया।