VPN ले OpenWrt सँग भेट्ने बित्तिकै तीन परिवर्तन मिसिन्छन्: पोर्ट खोल्नु, फर्वार्डिङको अनुमति दिनु र मास्करेडिङ सुरु गर्नु। ती फरक प्रश्नको जवाफ दिन्छन्, र सामान्यतया तीमध्ये एउटा मात्र वास्तविक आवश्यकता हुन्छ। प्रत्येक नियन्त्रणलाई त्यसले नियन्त्रण गर्ने ट्राफिक भूमिकाअनुसार पढ्दा अनुमान निर्णयमा बदलिन्छ, र परिवर्तन गलत हुँदा कुन लक्षण अपेक्षा गर्ने भन्ने पनि बताउँछ। तपाईंले सम्झेको चेकबक्स होइन, असफल भएको भूमिकाको नाम लिएर सुरु गर्नुहोस्।

कुनै नियन्त्रण छुनु अघि ट्राफिक भूमिकाको नाम राख्नुहोस्

जोन इनपुटले राउटरसम्म के पुग्न सक्छ भनेर निर्धारण गर्छ। जोन आउटपुटले राउटर आफैले बनाउने ट्राफिक समेट्छ, जोन फर्वार्डिङ जोनबाट जाने ट्राफिकको पूर्वनिर्धारित मान हो, र मास्करेडिङले बाहिर जाँदा स्रोत ठेगाना फेरि लेखिने वा नहुने निर्धारण गर्छ। यी चार फरक प्रश्न हुन्, र जोन नीतिले एउटै मानले चारैको जवाफ एकैचोटि दिन्छ, त्यसैले पूरै जोनमा गरिने परिवर्तन ठूलो हतियार हो। नाम दिइएको नियमले बाँकीलाई छोइकन तीमध्ये एउटाको जवाफ दिन सक्छ।

उपयोगी नक्सा ट्राफिक भूमिकाअनुसार हुन्छ, किनकि केही असफल हुँदा तपाईंले अवलोकन गर्न सक्ने कुरा त्यही हो। तलका प्रत्येक भूमिकासँग त्यसलाई निर्धारण गर्ने एउटा नियन्त्रण र त्यसतर्फ देखाउने एउटा लक्षण छ:

Traffic roleControl that decides itWhere it lives in the configSymptom when it is wrong
A client reaching a listener on the routerInput policy of the zone that carries the connection, or a rule for the portoption input in the zone stanza, or a named ruleThe handshake never completes and the tunnel log says nothing
A tunnel client reaching the router itselfInput policy of the tunnel zoneoption input in the VPN zoneA ping to the gateway fails
A tunnel client reaching another LAN hostForwarding from the tunnel zone to the LAN zoneconfig forwarding plus the zone assignmentThe gateway answers and the file share times out
The router's own traffic leaving the WANOutput policy, and translation if the far side needs itoption output and option masqThe tunnel never establishes, or replies vanish

राउटरमा सुन्ने सेवालाई एउटा साँघुरो इनपुट नियम चाहिन्छ

राउटरमा रहेको OpenVPN सर्भरले राउटरलाई सम्बोधित ट्राफिक प्राप्त गर्छ, त्यसैले त्यसको बाह्य जडान त्यसलाई बोक्ने जोनको इनपुट नीतिमा निर्भर हुन्छ। कन्फिगर गरिएको ट्रान्सपोर्ट र पोर्टलाई अनुमति दिनुहोस् र त्यो जोनमा बाँकी सबै अस्वीकृत राख्नुहोस्। एउटा पोर्ट नियम पूरै जोनको अनुमतिभन्दा धेरै सानो परिवर्तन हो, र एक वर्षपछि पनि तपाईंले व्याख्या गर्न सक्ने त्यही हो।

दुई कुराले त्यो नियम राख्न सुरक्षित बनाउँछन्: यसले सेवाले वास्तवमै प्रयोग गर्ने पोर्टको नाम लिन्छ, र यो जोनको परिभाषाको छेउमा रहन्छ ताकि अर्को व्यक्तिले यो किन छ भनेर देख्न सकोस्। तलका लाइनहरू केवल आकार हुन्, पोर्टले सर्भरमा कन्फिगर गरिएको मानको प्रतिनिधित्व गर्छ। सेवा सर्ने बेला त्यो पोर्ट दुवै ठाउँमा बदल्नुहोस्, किनकि पुरानोमा रहेको नियम अडिटसम्म अदृश्य रहन्छ।

config zone
    option name 'wan'
    option input 'REJECT'
    option forward 'REJECT'
    option output 'ACCEPT'
    option masq '1'

config rule
    option name 'allow-openvpn'
    option src 'wan'
    option proto 'udp'
    option dest_port '1194'
    option target 'ACCEPT'

पुनः लोड गर्नु अघि प्रमाणित गर्नुहोस्, किनकि फायरवाल फाइलमा भएको वाक्यरचना त्रुटिले राउटरलाई काम गर्ने नियमसङ्ग्रह बिना छोड्न सक्छ। fw4 प्रयोग गर्ने संस्करणमा जाँच अलग आदेश हो, र यसले बिग्रिएको खण्ड चुपचाप स्वीकार गर्नुको सट्टा ठूलो स्वरमा असफल हुन्छ। जाँच उत्तीर्ण भएपछि मात्र पुनः लोड गर्नुहोस्, र अघिल्लो फाइल जहाँबाट फर्काउन सकिन्छ त्यहाँ राख्नुहोस्।

fw4 check
service firewall reload

क्लाइन्टको अनुरोध इनपुटबाट होइन, फर्वार्डिङबाट जान्छ

प्रमाणीकरणपछि, LAN सेवा माग्ने टनेल क्लाइन्टको अनुरोधले फर्वार्ड गरिएको प्रवाह बनाउँछ, त्यसैले त्यसलाई निर्धारण गर्ने नियन्त्रण टनेल जोन र LAN जोनबीचको फर्वार्डिङ सम्बन्ध हो। टनेल इन्टरफेसलाई इच्छित जोनमा तोक्नुहोस्, त्यसपछि दिशा, स्रोत र सेवा घोषणा गर्नुहोस्। जोन तोकाइले नै फर्वार्डिङ नियमलाई अर्थ दिन्छ, र दुवै सँगै पढ्दा मात्र बुझिन्छ। टनेल जोनलाई स्रोत र LAN जोनलाई गन्तव्य भन्ने फर्वार्डिङ सम्बन्ध एक जानाजानको निर्णयका रूपमा पढिन्छ, जबकि पूरै जोनका दुई अनुमति दुर्घटनाका रूपमा पढिन्छन्।

राउटरसम्म पुग्न अझै इनपुट मार्ग प्रयोग हुन्छ, त्यसैले गेटवेमा ping ले त्यसको पछाडिको फाइल साझेदारीबारे केही भन्दैन। ती दुई असफलता फरक खण्डमा बस्छन् र फरक परिवर्तनले सुधारिन्छन्। कुनै एउटा बदल्नु अघि दुवै मार्ग छुट्टाछुट्टै लेख्नुहोस्।

मास्करेडिङ राउटिङको निर्णय हो, अनुमति होइन

मास्करेडिङले छानिएको बाहिर जाने ट्राफिकको स्रोत ठेगाना फेरि लेख्छ। दूरको पक्षसँग फर्कने मार्ग नभएको निकास संरचनालाई यसले बचाउन सक्छ, र ठेगाना लग गर्ने वा ठेगानाका आधारमा अनुमति दिने कुनै पनि सेवाबाट व्यक्तिगत क्लाइन्टका ठेगाना पनि लुकाउँछ। यसलाई बन्द गर्नु फर्कने मार्गबारेको राउटिङ विकल्प हो, भित्री प्वाल बन्द गर्ने सुरक्षा स्विच होइन। अनुवाद खुला हुँदा चल्ने र बन्द गर्ने क्षणमै असफल हुने टनेलमा सामान्यतया फर्कने मार्ग हराएको हुन्छ, फायरवाल नियम होइन।

राउट गरिएको विकल्पलाई अनुवादको सट्टा दूरको पक्षमा फर्कने मार्ग चाहिन्छ। दुवै विकल्पले फायरवाल अनुमति वा अनुप्रयोग खाता दिँदैनन्, त्यसैले मास्करेडिङ बन्द गर्नाले कतै पुग्न नसक्ने टनेल क्लाइन्टलाई लगभग कहिल्यै सुधार्दैन। IPv4 र IPv6 नीतिलाई पनि छुट्टै हेर्नुहोस्, किनकि एउटा अनुवाद सेटिङले दुवै परिवारको वर्णन गर्दैन।

अनुमति दिइएको र अस्वीकृत अनुरोधले निर्णय प्रमाणित गर्नुहोस्

अनुमति दिनुपर्ने एउटा अनुरोध र अस्वीकार गर्नुपर्ने एउटा अनुरोध पठाउनुहोस्, त्यसपछि प्रत्येक निर्णय लिने नियन्त्रण पहिचान गर्नुहोस्। संयोगले लोड भएको पृष्ठ प्रमाण होइन; प्रमाण भनेको मिलेको नियम हो, जुन शृंखलामा मिल्यो त्यहीँ। अस्वीकार सफलताइतिकै महत्त्वपूर्ण छ, किनकि सबै अनुमति हुनुको सट्टा नीतिले केही गरिरहेको छ भनेर यसले देखाउँछ।

हालको संस्करणमा दुई आदेशले त्यो प्रमाण दिन्छन्। अनुरोध स्वीकार गरिँदा मिल्ने नियमको काउन्टर सर्छ, र नियमका लागि लगिङ खोलेको भए लगले ड्रप देखाउँछ:

nft list chain inet fw4 forward_wan
logread -f | grep -i -E 'DROP|REJECT'

कुनै पनि फायरवाल नीति बदल्नु अघि अझै प्रयोग गर्न सकिने प्रशासन मार्ग राख्नुहोस्, र कन्फिगरेसनको मालिकको प्रमाणीकरण र रोलब्याक प्रक्रिया पालना गर्नुहोस्। तपाईंलाई राउटरबाहिर ताला लगाउने परिवर्तन परीक्षणको नतिजा होइन, त्यो दोस्रो घटना हो। प्रत्येक अवलोकनको छेउमा जोन र ट्राफिक भूमिका लेख्नुहोस्, ताकि नतिजाको जोडीले भाग्यशाली पृष्ठ लोडको वर्णन होइन, नीतिको व्याख्या गरोस्।

सम्बन्धित लेखहरू