UFW नियमहरूले OpenVPN गेटवेलाई एउटै LAN मा सीमित गर्नुहोस्

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

पहिले टोपोलोजी र अनुमति लेख्नुहोस्

उदाहरणले प्रयोगकर्ता क्षेत्रको TUN यन्त्रलाई भनिने Community OpenVPNtun0 सर्भर, ग्राहक पूल 10.77.0.0/24, र एउटा जोडिएको सबनेट 192.168.60.0/24 lan0 मा प्रयोग गर्छ। IPv4 फर्वार्डिङ पहिले नै काम गर्छ र LAN सँग पूलतर्फ फर्कने मार्ग पहिले नै छ, त्यसैले यहाँ केही पनि तिनीहरूबीचको अनुवादमा निर्भर छैन।

यो होस्टको फायरवाल UFW को स्वामित्वमा छ, र कुनै कन्टेनर नियमसमूह वा छुट्टै nftables तालिकाले अघिल्लो स्वीकृति मार्ग राख्न सक्दैन। फिल्टर छल्ने फ्लो-अफलोड सर्टकटले गार्ड शृंखलाहरूलाई केवल सजावट बनाउँछ, त्यसैले कुनै पनि सक्रिय छैन भनी सुनिश्चित गर्नुहोस्। OpenVPN को आफ्नै client-to-client फर्वार्डिङ बन्द राख्नुहोस्, किनकि अपरेटिङ सिस्टमको फिल्टर कहिल्यै नाघ्ने सहकर्मीहरूबीचको ट्राफिक त्यसले सीमित गर्न सकिँदैन। बाह्य श्रोता र प्रशासनिक नियमहरू जस्ताको तस्तै रहन्छन्, किनकि यो परिवर्तनले फायरवाल बदल्नुको सट्टा डिक्रिप्ट गरिएको टनेल ट्राफिक नियन्त्रण गर्छ।

गार्डहरूलाई UFW का प्रारम्भिक स्वीकृतिहरू अघि राख्नुहोस्

मार्ग अनुमति र त्यसपछिको अस्वीकृति कडा सीमाका लागि पर्याप्त हुँदैन। स्टक before नियमहरूले कुनै पनि प्रयोगकर्ता नियम हेर्नु अघि नै स्थापित ट्राफिक र केही ICMP स्वीकार गर्छन्, त्यसैले गत हप्ता अनुमति दिइएको प्रवाह नयाँ गन्तव्य प्रतिबन्धबाहिर रहन सक्छ, केवल यसकारण कि त्यसको स्थिति अझै छ। UFW फाइलहरूको ब्याकअप लिनुहोस् र सम्पादन अघि आउट-अफ-ब्यान्ड कन्सोल खुला राख्नुहोस्।

फाइलको *filter खण्डमा /etc/ufw/before.rules, विद्यमान घोषणाहरूको छेउमा र कुनै पनि नियम लाइन अघि दुई शृंखलाहरू घोषणा गर्नुहोस्।

:vpn-src-guard - [0:0]
:vpn-reply-guard - [0:0]

घोषणाहरूपछि तुरुन्तै, र इनपुट तथा फर्वार्डिङ अनुमतिहरू अघि, तिनीहरूभित्र हाम्फाल्नुहोस् र के स्वीकार गर्छन् परिभाषित गर्नुहोस्।

-A ufw-before-input -i tun0 -j DROP
-A ufw-before-forward -i tun0 -j vpn-src-guard
-A ufw-before-forward -o tun0 -j vpn-reply-guard

-A vpn-src-guard -o lan0 -d 192.168.60.0/24 -s 10.77.0.0/24 -m conntrack --ctdir ORIGINAL -j RETURN
-A vpn-src-guard -j DROP

-A vpn-reply-guard -i lan0 -d 10.77.0.0/24 -s 192.168.60.0/24 -m conntrack --ctstate RELATED,ESTABLISHED --ctdir REPLY -j RETURN
-A vpn-reply-guard -j DROP

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

हरेक गार्डले के स्वीकार गर्छ र के अस्वीकार गर्छ पढ्नुहोस्

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

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

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

सबनेटलाई अधिकृत गर्नुहोस् र छेउका ढोका बन्द गर्नुहोस्

पहिले मार्ग अनुमतिको पूर्वावलोकन गर्नुहोस्, त्यसपछि लागू गर्न पूर्वावलोकन झन्डा हटाउनुहोस्: sudo ufw --dry-run route allow in on tun0 out on lan0 from 10.77.0.0/24 to 192.168.60.0/24. त्यसपछि प्रयोगकर्ता नियमहरूको क्रम समीक्षा गर्नुहोस्, किनकि अघिल्लो अस्वीकृति पछिको अनुमतिलाई अझै जित्छ। पूरै सबनेटको अनुमति पनि गलत आकार हो जब एउटा होस्टको HTTPS पोर्ट मात्र पहुँचयोग्य हुनुपर्छ।

इनपुट खारेजले के गर्छ ध्यान दिनुहोस्: टनेल ग्राहकहरू गेटवेमै कुनै पनि सेवामा पुग्न सक्दैनन्, त्यसको LAN ठेगानामा बाँधिएको DNS श्रोता सहित। त्यहाँ DNS होस्ट गर्न खारेज अघि जानाजानी गरिएको अपवाद र परिमार्जित अनुमति करार चाहिन्छ। यदि UFW ले IPv6 व्यवस्थापन गर्छ भने, tun0 का लागि before6.rules फाइलमा पनि मिल्ने खारेजहरू थप्नुहोस्, किनकि IPv4 गन्तव्य सूचीले IPv6 प्याकेटबारे केही भन्दैन।

पूर्वावलोकन होइन, लोड गरिएको नीति प्रमाणित गर्नुहोस्

पुनःलोडको पूर्वावलोकन गर्नुहोस्, मर्मत झ्यालमा लागू गर्नुहोस्, र जीवित नियमसमूह पढ्नुहोस्।

sudo ufw --dry-run reload
sudo ufw show raw

टनेल गार्डहरू पूर्वनिर्धारित स्थिति र ICMP अनुमतिहरू अघि देखिन्छन् भनी पुष्टि गर्नुहोस्। सादा ufw status ले हातले सम्पादित before नियमहरू देखाउँदैन, त्यसैले सञ्चालकहरू नियम हराएको निष्कर्षमा पुग्छन् जबकि त्यो वास्तवमा लोड भएको हुन्छ। टुक्रा खोज्नुको सट्टा कच्चा सूची माथिबाट तल पढ्नुहोस्। यदि गार्डहरू स्थिति अनुमति पछि देखिन्छन् भने, सीमाले फाइलले भनेको गर्दैन।

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

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