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