टनेल नरोकी एक OpenVPN क्लाइन्टलाई LAN बाट ब्लक गर्नुहोस्
क्लाइन्टको टनेल ठेगाना यसको प्रमाणपत्रमा पिन गर्नुहोस्, FORWARD को सुरुमा यसको LAN ट्राफिक खसाल्नुहोस्, त्यसपछि IPv6, ट्र्याक गरिएका सत्र र रिबुटपछिको टिकाइ जाँच्नुहोस्।
तपाईंको OpenVPN सर्भरमा एउटा क्लाइन्टले LAN पहुँच गुमाउनुपर्छ जबकि अन्य सबै टनेल चालु रहनुपर्छ। यो खोज्दा उत्कृष्ट उत्तरले प्रायः डेमनले यो गर्न सक्दैन भन्छ, जुन आधा मात्र सत्य हो: OpenVPN मा प्रति-क्लाइन्ट फायरवाल छैन, तर टनेल अन्त्य गर्ने होस्टले पहिले नै प्याकेट फिल्टर गर्छ। महत्त्वपूर्ण दुई निर्णय भनेको तपाईंले ब्लक गर्ने पहिचान र नियमको स्थान हुन्। यी दुवै सही गर्नुभयो भने परिवर्तन परीक्षण र हटाउन सकिने एक लाइन बन्छ।
नियम लेख्नु अघि क्लाइन्ट पिन गर्नुहोस्
OpenVPN ले पूलबाट टनेल ठेगानाहरू भाडामा दिन्छ, त्यसैले 10.8.0.6 व्यक्ति होइन, सिट हो। सत्र सकिएपछि भाडा फर्किन्छ र अर्को जडानलाई दिन सकिन्छ, अर्थात् त्यो ठेगानाविरुद्ध लेखिएको नियम सिटलाई पछ्याउँछ, प्रयोगकर्तालाई होइन। त्यसैले पहिले तपाईंले वास्तवमा के ब्लक गर्दै हुनुहुन्छ निर्णय गर्नुहोस्: छोटो प्रयोगका लागि ठेगाना, वा बाहिर राख्न चाहेको व्यक्तिको प्रमाणपत्र।
ठेगानालाई प्रमाणपत्रसँग बाँध्न, client-config-dir ले नाम दिएको डाइरेक्टरीमा फाइल बनाउनुहोस् र फाइललाई प्रमाणपत्रको common name ठ्याक्कै दिनुहोस्। त्यसमा एउटा निर्देश राख्नुहोस्, ifconfig-push 10.8.0.6 255.255.255.0, र त्यो क्लाइन्टले पुनः जडानमा पनि त्यही टनेल ठेगाना राख्छ। यो प्रभावकारी हुन दुई सेटिङ हुनुपर्छ: सर्भर कन्फिगरेसनमा client-config-dir घोषणा गरिएको हुनुपर्छ, र पठाइएको ठेगाना सर्भरले रुट गर्न सक्ने सबनेटमा हुनुपर्छ। एउटा छुट्यो भने फाइल कुनै त्रुटिबिना बेवास्ता गरिन्छ, जसले अर्को फायरवाल परीक्षणलाई भ्रमित बनाउँछ।
अस्थायी ब्लकले पूलको ठेगाना प्रयोग गर्न सक्छ, यदि टिकटमा त्यसबेला कुन सत्रले यो राखेको थियो भनी लेखिएको छ भने।
क्रमले ड्रप चल्ने वा नचल्ने निर्धारण गर्छ
टनेल र LAN बीच फर्वार्ड गर्ने Linux गेटवेमा प्याकेटहरू FORWARD चेन पार गर्छन्। तलको आदेशलाई वाक्यको रूपमा पढ्नुहोस्: FORWARD को सुरुमा घुसाउनुहोस्, tun0 बाट आउने, त्यही एउटा होस्टको, LAN सबनेटतर्फ लक्षित ट्राफिक मिलाएर खसाल्नुहोस्।
iptables -I FORWARD -i tun0 -s 10.8.0.6/32 -d 192.168.1.0/24 -j DROP-I ले नियम चलाउँछ। -A सँग थप्दा यो टनेल सबनेटका लागि कुनै पनि फराकिलो स्वीकृतिको तल पर्छ र कहिल्यै प्याकेट देख्दैन। स्थान iptables -vnL FORWARD --line-numbers ले जाँच्नुहोस् र काउन्टर पनि पढ्नुहोस्: माथिको ड्रपले केही गन्दैन भने ट्राफिक अर्को बाटोबाट आइरहेको छ।
गेटवेको आफ्नै LAN ठेगाना अर्को बाटो हो। बक्समै पठाइएका प्याकेट INPUT मा जान्छन्, FORWARD मा होइन, त्यसैले क्लाइन्टले LAN होस्ट गुमाए पनि राउटरको एडमिन पृष्ठ खोल्न सक्छ। त्यो महत्त्वपूर्ण हुँदा मिल्ने INPUT नियम थप्नुहोस्।
फिल्टरले देख्न नसक्ने कुरा
प्याकेट मूल्याङ्कन हुँदा फिल्टरिङ हुन्छ, त्यसैले स्थापित TCP सत्र बन्द वा रिसेट नहुँदासम्म चल्न सक्छ। ब्लकले तुरुन्तै काम गर्नुपर्ने भए नियम राखेपछि त्यो स्रोतका ट्र्याक गरिएका फ्लो conntrack -D -s 10.8.0.6 ले सफा गर्नुहोस्। केही सेकेन्डको ओभरल्याप स्वीकार्य भए त्यो छनोट लेख्नुहोस्, अन्तर्निहित छाड्नु हुँदैन। जसरी भए पनि, अर्को व्यक्तिले यो नियम जीवित ट्राफिक रोक्छ कि नयाँ जडान मात्र भन्ने थाहा पाउनुपर्छ।
पीयरहरूबीचको ट्राफिकले कहिल्यै होस्ट फायरवाल छुँदैन। client-to-client सक्षम हुँदा OpenVPN ले ती प्याकेट डेमनभित्रै पठाउँछ, त्यसैले FORWARD वा INPUT ले ती देख्दैनन्। एकमात्र उपाय client-to-client बन्द गर्नु वा पीयरहरू एकअर्कासम्म पुग्न सक्छन् भनी स्वीकार्नु हो; iptables नियमले त्यो ट्राफिक देख्ने छैन।
IPv6, फर्मवेयर र रिबुटपछिको टिकाइ
IPv4 नियमले IPv6 बारे केही भन्दैन। टनेल र LAN दुवै परिवार बोक्छन् भने, समतुल्य नियम ip6tables मा वा त्यो होस्टमा नीति राख्ने nftables नियमसमूहमा हुनुपर्छ। राउटर फर्मवेयरले प्रायः netfilter लाई आफ्नै अमूर्ततापछि लुकाउँछ, त्यसैले फोरमबाट प्रतिलिपि गरिएको सिन्ट्याक्स र तालिका नाम लागू नहुन सक्छ।
OpenWrt मा कागजात गरिएको बाटो फायरवाल कन्फिगरेसन प्रविष्टि हो, हातले लेखिएको iptables लाइन होइन, र हातले लेखिएको लाइन फायरवाल पुनः लोड हुँदा हराउन सक्छ। अन्य वितरणहरूले नियमहरू netfilter-persistent, बुट युनिट वा विक्रेताको भण्डारमार्फत पुनर्स्थापित गर्छन्, र ती संयन्त्रहरू परस्पर विनिमययोग्य छैनन्। तपाईंले छानेको रिबुटले प्रमाणित गर्नुहोस्, किनभने पुनः लोडले अर्को बाटो अभ्यास गर्छ।
बाटोअनुसार जाँच्नुहोस्, त्यसपछि सफासँग फर्काउनुहोस्
प्रत्येक बाटो छुट्टै परीक्षण गर्नुहोस्, किनभने एउटा सफल जाँचले अरूलाई लुकाउँछ। ब्लक गरिएको क्लाइन्टले टनेलबाट इन्टरनेट पुग्नुपर्छ तर LAN होस्टमा असफल हुनुपर्छ, दोस्रो क्लाइन्टले त्यही होस्ट पुग्नुपर्छ, र गेटवे ठेगाना र पीयर बाटोलाई प्रत्येकले आफ्नै अवलोकन चाहिन्छ। नतिजा नियमको छेउमा लेख्नुहोस् ताकि अर्को परिवर्तनलाई आधार मिलोस्। तलको तालिका टिकटमा राख्न लायक समूह हो।
| बाटो | नियमसहित अपेक्षित | असफल हुँदा |
|---|---|---|
| ब्लक गरिएको क्लाइन्ट LAN होस्टतर्फ | कुनै जवाफ छैन | नियम स्वीकृतिको तल छ, वा स्रोत मिल्दैन |
| ब्लक गरिएको क्लाइन्ट इन्टरनेटतर्फ | tun0 बाट काम गर्छ | नियम धेरै फराकिलो छ, गन्तव्य मिलान छैन |
| दोस्रो क्लाइन्ट त्यही LAN होस्टतर्फ | काम गर्छ | नियमले अभिप्रेत होस्टभन्दा बढी मिलायो |
| ब्लक गरिएको क्लाइन्ट गेटवेको LAN ठेगानातर्फ | मिल्ने INPUT नियम भएमा मात्र ब्लक | INPUT नियम छैन |
| ब्लक गरिएको क्लाइन्ट पीयर टनेल ठेगानातर्फ | अझै काम गर्छ | client-to-client सक्षम छ र फायरवालको दायराबाहिर |
फर्काउनु भनेको विशिष्टताअनुसार हटाउनु हो, फ्लश होइन: iptables -D FORWARD -i tun0 -s 10.8.0.6/32 -d 192.168.1.0/24 -j DROP ले ठ्याक्कै त्यो प्रविष्टि हटाउँछ र चेनको बाँकी अक्षुण्ण राख्छ। बुटमा नियम पुनर्स्थापित गर्ने कुनै पनि फाइलबाट त्यही लाइन हटाउनुहोस्, पुनः लोड गर्नुहोस्, र क्लाइन्ट फेरि LAN होस्टमा पुग्छ भनी पुष्टि गर्नुहोस्। FORWARD फ्लश गर्दा तपाईंले नलेखेका नियम पनि रद्द हुन्थे, जसले फर्काउने कामलाई दोस्रो घटना बनाउँछ।
टिकट बन्द गर्नु अघि तीन कुरा पुष्टि गर्नुहोस्: पिन गरिएको ठेगाना प्रमाणपत्रसँग मिल्छ, नियम स्वीकृतिहरूमाथि छ र काउन्टर शून्य छैन, र स्थायित्व फाइलमा तपाईंले परीक्षण गरेको त्यही नियम छ। यीमध्ये कुनै छैन भने, ब्लक शेल सत्रको भ्रम हो।