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'

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

संबंधित लेख