OpenVPN से जुड़े हैं लेकिन पिंग या SMB शेयर नहीं? तीन द्वार जाँचें
काम करता टनल फ़ॉरवर्डिंग, SMB पोर्ट या नाम हल होने के बारे में कुछ नहीं बताता। हर द्वार को क्रम से जाँचें और पहले असफल होने पर रुकें।
टनल ऊपर आ जाता है, क्लाइंट को पता मिल जाता है, और दूर के LAN पर कोई जवाब नहीं देता। पिंग विफल होता है, शेयर नहीं खुलता, और VPN लॉग साफ़ दिखता है क्योंकि उसकी नज़र में सत्र स्वस्थ है। उस सत्र और सर्वर पर रखी फ़ाइल के बीच तीन स्वतंत्र द्वार हैं: फ़ॉरवर्डिंग नीति, सेवा को ज़रूरी पोर्ट, और वह नाम जो आपने पते की जगह टाइप किया।
हर द्वार अलग लक्षण के साथ विफल होता है, और केवल पहला ही VPN सर्वर पर है।
फ़ॉरवर्डिंग FORWARD चेन पर एक नीति है
OpenVPN सुनने वाले की स्वीकृति INPUT पर होती है, इसीलिए टनल जुड़ सकता है जबकि LAN की ओर जाने वाला हर पैकेट गिरा दिया जाता है। जो ट्रैफ़िक tun0 से आता है और LAN इंटरफ़ेस से बाहर जाता है, वह FORWARD से गुज़रता है, और वहाँ डिफ़ॉल्ट DROP नीति वाला होस्ट उसे चुपचाप गिरा देता है। कुछ और छूने से पहले sysctl और चेन दोनों जाँचें: sysctl net.ipv4.ip_forward और iptables -L FORWARD -v -n।
जो दिशा आप चाहते हैं और उससे जुड़े जवाबों को अनुमति दें, उदाहरण के लिए टनल इंटरफ़ेस से LAN इंटरफ़ेस तक एक accept नियम और established तथा related ट्रैफ़िक के लिए एक stateful नियम। अगर LAN किसी दूसरे राउटर के पीछे है, तो उस राउटर को क्लाइंट पूल तक वापसी रूट या VPN सर्वर पर source NAT चाहिए। और नियम जोड़ने से पहले एक पिंग से उस रास्ते की पुष्टि करें, क्योंकि जिस नियम तक पहुँचा नहीं जा सकता वह कभी काउंटर में नहीं दिखता।
SMB को एक से अधिक पोर्ट चाहिए
फ़ाइल शेयरिंग एक ही TCP 445 बातचीत नहीं है। खोज UDP 137 और 138 इस्तेमाल करती है, पुराने NetBIOS सत्र TCP 139 इस्तेमाल करते हैं, और आधुनिक SMB सत्र TCP 445 इस्तेमाल करते हैं। केवल 445 खोलने वाला नियम वह खीझ भरी स्थिति बनाता है जिसमें मैप किया गया ड्राइव काम करता है और नेटवर्क ब्राउज़ करना नहीं, या उलटा।
टनल पर बड़े ट्रांसफ़र भी MSS समस्याओं से टकराते हैं जो टूटे शेयर जैसी दिखती हैं। जो SYN LAN का पूरा सेगमेंट आकार बताता है वह टनल के छोटे MTU से गिरा दिया जाता है, और हैंडशेक के बाद कनेक्शन अटक जाता है। फ़ॉरवर्डिंग रास्ते पर MSS क्लैंप करना, iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu, उस तरह की रुकावट को हटा देता है। डायरेक्टरी लिस्टिंग की जगह कुछ मेगाबाइट की कॉपी से जाँचें, क्योंकि छोटे जवाब तब भी निकल जाते हैं जब बल्क ट्रांसफ़र नहीं निकलते।
टनल अडैप्टर नए नेटवर्क प्रोफ़ाइल के रूप में आता है
Windows हर अडैप्टर को एक नेटवर्क प्रोफ़ाइल में वर्गीकृत करता है, और नया टनल अडैप्टर आमतौर पर Public में पड़ता है, जहाँ फ़ाइल और प्रिंटर शेयरिंग के नियम ब्लॉक रहते हैं। यह फ़ाइल सर्वर पर होस्ट फ़ायरवॉल का फ़ैसला है, VPN सर्वर पर राउटिंग की समस्या नहीं। नीति अनुमति देती है यह पक्का करने के बाद जानबूझकर श्रेणी बदलें Set-NetConnectionProfile -InterfaceAlias "Ethernet 3" -NetworkCategory Private से, क्योंकि श्रेणी यह भी बदल देती है कि कौन से इनबाउंड नियम लागू होंगे।
वही प्रोफ़ाइल उस पिंग को समझाती है जो विफल होता है जबकि TCP 445 सफल होता है: Public में इको अनुरोध डिफ़ॉल्ट रूप से गिरा दिए जाते हैं।
नाम अपने आप राउटेड टनल पार नहीं करते
NetBIOS नाम हल करना और स्थानीय खोज ऐसे ब्रॉडकास्ट पर निर्भर हैं जो राउटेड टनल नहीं ढोता। इसलिए सर्वर का छोटा नाम टाइप करना विफल होता है जबकि उसका पता काम करता है, और शेयर टूटा जैसा दिखता है जबकि टूटा केवल लुकअप है। टनल जो रिज़ॉल्वर देता है उस पर सर्वर के लिए DNS रिकॉर्ड जोड़ें, या शॉर्टकट में पता इस्तेमाल करें।
अगर परिनियोजन अब भी WINS पर निर्भर है, तो ब्रॉडकास्ट ट्रैफ़िक आने की उम्मीद की जगह क्लाइंट पर इसे कॉन्फ़िगर करें। पहले पते से जाँचें ताकि नाम की विफलता फ़ायरवॉल की विफलता न समझी जाए।
एक समय में एक परत जाँचें और पहली विफलता पढ़ें
ऊपर की ओर बढ़ें: टनल गेटवे को पिंग करें, पते से LAN होस्ट को पिंग करें, फिर Test-NetConnection -ComputerName 10.8.0.5 -Port 445 से सेवा का पोर्ट खोलें, और उसके बाद ही शेयर पर प्रमाणीकरण करें। जो पहला कदम विफल होता है वही परत ठीक करनी है, और उसके बाद का हर कदम शोर है जब तक वह पार न हो जाए। जो पिंग जवाब देता है जबकि पोर्ट बंद रहता है वह फ़ाइल सर्वर के अपने फ़ायरवॉल की ओर इशारा करता है, जबकि चुपचाप पिंग के बावजूद खुलने वाला पोर्ट ICMP फ़िल्टरिंग की ओर इशारा करता है। कुछ भी बदलने से पहले पहला विफल कदम लिख लें, क्योंकि दूसरा बदलाव पहले के नतीजे को छिपा देता है।
अगर VPN सर्वर LAN का राउटर नहीं है, उस राउटर पर वापसी रूट की पुष्टि करें सर्वर पर और नियम जोड़ने से पहले। इसके बिना अनुरोध होस्ट तक पहुँचते हैं और जवाब डिफ़ॉल्ट रूट से इंटरनेट की ओर निकल जाते हैं, जो क्लाइंट की तरफ़ से बिल्कुल फ़ायरवॉल ड्रॉप जैसा दिखता है।
अपने नोट्स में शेयर खाते को VPN लॉगिन से अलग रखें, क्योंकि सफल टनल फ़ाइल अनुमतियों के बारे में कुछ नहीं बताता। छूटा नियम बचाने के लिए SMB को इंटरनेट पर खोलना समाधान नहीं है।