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 रिफ्लेक्टरपेक्षा वेगळा प्रोटोकॉल आणि अनेकदा वेगळे गंतव्य वापरते, आणि दोन्हींमधील मतभेद सामान्यतः बग नसून मार्गनिर्देशन नियमाकडे निर्देश करतो।
धोरण ठरवा, मग उत्तर वाचा
चाचणीपूर्वी हेतू लिहा: कोणत्या रहदारीने टनेल वापरावा, कोणती थेट बाहेर पडू शकते, कोणती पत्ता-कुटुंबे व्याप्तीत आहेत, आणि टनेल बंद असताना काय व्हावे। त्या आधाररेषेशिवाय प्रत्येक निरीक्षण संदिग्ध आहे, कारण जाणूनबुजून अनुमती दिलेल्या मार्गापासून गळती वेगळी करता येत नाही।
मग एका वेळी एक प्रश्न विचारा। हे गंतव्य कोणता मार्ग घेते। हा रिफ्लेक्टर कोणता पत्ता नोंदवतो। सत्राने कोणती उमेदवार जोडी निवडली। उत्तरे धोरणाजवळ ठेवा आणि तारीख घाला, कारण फर्मवेअर अद्ययावत डीफॉल्ट वर्तन अशा प्रकारे बदलू शकते जे गेल्या वर्षीचा निष्कर्ष शांतपणे रद्द करते।
राउटर अजूनही मजबूत अंमलबजावणी बिंदू आहे, कारण तो असा रहदारी पाहतो जो क्लायंट स्वतःला पुन्हा संरचीत केल्याशिवाय टाळू शकत नाही। प्रत्येक अनुप्रयोग प्रोटोकॉलमधील प्रत्येक क्षेत्र काहीही उघड करत नाही हे वचन ते नाही, आणि अनुमती देण्याचे तुम्ही निवडलेले मार्ग लिहून ठेवण्याचा तो पर्यायही नाही।