राउटरवर VPN असताना STUN कोणता स्रोत पत्ता पाहतो?
मार्ग, स्रोताची निवड आणि भाषांतर परावर्तक जो पत्ता सांगतो तो ठरवतात। लिहायला तीन तथ्ये, मग कोणता मार्ग जिंकतो हे तपासण्यासाठी एक चौकशी।
प्रश्न एकच शोध वाटतो आणि प्रत्यक्षात तीन निर्णय आहेत। binding request कोणता मार्ग घेते, कर्नेल त्या मार्गासाठी कोणता स्रोत निवडते आणि वाटेत काही तो स्रोत पुन्हा लिहिते का। यांपैकी कोणतेही एक बदला आणि STUN सर्व्हर जो पत्ता सांगतो तोही त्याबरोबर बदलतो। म्हणूनच VPN राउटरवर आहे असे म्हणणे स्वतःहून जवळजवळ काहीच सांगत नाही।
निर्णय तीन तथ्यांवर उभा आहे
प्रथम मार्ग: धोरण नियम आणि मार्ग सारणी ठरवतात की विनंती सुरंगातून बाहेर जाईल की सामान्य WAN मधून, आणि वगळलेले गंतव्य सुरंग सक्रिय असतानाही दुसरा मार्ग घेते। नंतर स्रोत: कर्नेल निवडलेल्या मार्गासाठी स्रोत निवडते, आणि ही निवड मार्गाच्या पसंतीच्या स्रोतावर आणि जुळलेल्या कोणत्याही नियमावर अवलंबून असते। शेवटी भाषांतर: वाटेत NAT निवडलेला स्रोत बदलते। परावर्तित पत्ता तिन्हींचा गुणाकार आहे, सुरंगाचा गुणधर्म नाही।
तिन्हींपैकी एक बदला आणि उत्तर बदलते, तर प्रत्येक घटक आपल्या लॉगमध्ये अजूनही निरोगी दिसतो। हेच या निदानाच्या अडकण्याचे नेहमीचे कारण आहे।
सुरुवातीपूर्वी ज्या प्रवाहाची चाचणी करत आहात त्यासाठी तीन तथ्ये लिहून घ्या। इंटरफेस, मार्ग आणि भाषांतर नियम निकालाचा अंदाज लावण्यासाठी पुरेसे आहेत, आणि हाच अंदाज आश्चर्याला माहितीपूर्ण बनवतो। तिन्हींपैकी एकही भरता येत नसेल, तर तीच तफावत खरी निष्पत्ती आहे।
एक binding request मार्गाने पाहा
STUN ची binding request सर्व्हरला निरीक्षण केलेला स्रोत वाहतूक पत्ता सांगण्यास सांगते। उत्तर विनंतीने घेतलेल्या मार्गाचे वर्णन करते, क्लायंट मशीनवरील इंटरफेसची यादी नाही। दोन मार्गांनी आलेल्या दोन विनंत्या प्रामाणिकपणे दोन वेगळे पत्ते सांगतील।
| Path taken | Source the reflector sees | What it means |
|---|---|---|
| Tunnel to a public exit that translates | The exit's public address | The reflector learns nothing about the LAN |
| Tunnel to a private reflector, translated to the tunnel address, no later translation | That tunnel address | An internal identifier is disclosed to that reflector |
| Excluded flow over the ordinary WAN | The WAN address | The tunnel was not used at all |
हा तक्ता अटींचा संच म्हणून वाचा, पुरवठादारांची यादी म्हणून नाही। मधली ओळ असे मागते की खाजगी परावर्तक सुरंगाच्या स्वतःच्या मार्गनिर्देशन आणि समवयस्क धोरणाखाली पोहोचण्यायोग्य असेल; हे तपासता येणारे संरचना तथ्य आहे, खाते पातळी सूचित करते असे काही नाही। खालची ओळ धोरणासाठी सहसा महत्त्वाची असते, कारण तो रहदारी सुरंगातच राहायला हवा होता। त्यांच्यामध्ये नेहमीची स्थिती आहे, ज्यात बाहेर पडणारा भाग भाषांतर करतो आणि परावर्तक फक्त बाहेर पडणारा भाग पाहतो।
होस्ट उमेदवार आणि सर्व्हर-परावर्ती उमेदवार वेगवेगळ्या यंत्रणांमधून येतात, म्हणून उमेदवारांची यादी मीडियाने प्रत्यक्षात कोणता मार्ग वापरला हे सांगत नाही। सत्र कुठे गेले हे जाणून घ्यायचे असेल तर निवडलेली जोडी वाचा, संकलन लॉग नाही।
राउटरचा सुरंग पत्ता काय नाही
राउटरला दिलेला सुरंग पत्ता राउटरवरील एका इंटरफेसचा असतो। LAN होस्टवरील ब्राउझरचे स्वतःचे इंटरफेस पत्ते असतात आणि राउटरच्या सुरंग इंटरफेसचे थेट दर्शन नसते। दोन्हींना अदलाबदल करण्यायोग्य मानल्यास वेब पृष्ठ काय शिकू शकते याबद्दल आत्मविश्वासू चुकीची उत्तरे तयार होतात।
फॉरवर्डिंग ही दोन्हींना जोडणारी गोष्ट आहे। विनंती राउटरमधून मार्गित रहदारी म्हणून जाते, आणि तिचा स्रोत मार्गनिर्देशन आणि भाषांतराने तयार केलेला असतो।
सुरंगाचा मार्ग LAN स्रोत टिकवत असेल, तर खाजगी परावर्तक तो LAN पत्ता शिकू शकतो, जे खरे उघडकीस आणणे आहे आणि सुरंगाच्या पत्त्यापेक्षा वेगळे आहे। मार्ग सुरंगाच्या पत्त्यावर भाषांतर करत असेल, तर परावर्तक त्याऐवजी सुरंगाचा पत्ता शिकतो। दोन्ही निष्कर्ष एकाच होस्टवरील एकाच ब्राउझरशी सुसंगत आहेत, म्हणून निरीक्षण एखाद्या विशिष्ट प्रवाहाशी जोडले पाहिजे। ॲपला दोष देण्यापूर्वी कर्नेलला कोणता स्रोत वापरेल ते विचारा।
उघडकीस आणणे विरुद्ध बायपास: दोन निष्पत्ती, दोन दुरुस्त्या
परावर्तित सुरंग पत्ता तुम्ही परवानगी दिलेल्या मार्गावर अंतर्गत ओळखकर्ता उघड करतो। WAN वरून थेट विनंती तुम्हाला आवश्यक असलेल्या मार्गाला बायपास करते। पहिला माहितीचा प्रश्न आहे, दुसरा अंमलबजावणीचा, आणि दोन्ही वेगवेगळ्या ठिकाणी दुरुस्त होतात। दोन्हींना एका शब्दात मिसळल्यास अशी दुरुस्ती तयार होते जी एकालाही हाताळत नाही।
WebRTC हे अधिक दृश्यमान करते, ते चूक न करता, कारण उमेदवार गोळा करणे हे तो निवडण्यासारखे नाही।
ip route get 203.0.113.7 from 192.0.2.25
ip rule showप्रत्येक परवानगी दिलेल्या परावर्तक पत्त्यासाठी मार्ग चौकशी त्या स्रोतासह चालवा जो हा प्रवाह वाहून नेईल अशी अपेक्षा आहे, नंतर वगळलेल्या श्रेणींसाठी पुन्हा चालवा जेणेकरून पर्याय काय निवडतो ते दिसेल। दोन्ही उत्तरांची तुम्ही लिहिलेल्या धोरणाशी तुलना करा। ते तुमच्या हेतूने नसलेल्या पद्धतीने वेगळे असतील, तर ब्राउझरच्या उमेदवार यादीचा अर्थ लावण्याचीही गरज न देता तुम्ही दुरुस्तीचा बिंदू शोधला आहे।