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 समस्याहरू भोग्छन्। LAN को पूरा सेग्मेन्ट आकार घोषणा गर्ने SYN टनेलको सानो 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 इन्टरनेटमा खोल्नु समाधान होइन।