VPN जोडिएको छ तर फायरवालले अझै रोकिरहेको छ: कुन हो भनेर कसरी थाहा पाउने

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

बाटोलाई नीतिबाट अलग गर्नुहोस्

असफलताको आकारबाट सुरु गर्नुहोस्, किनकि त्यो निःशुल्क जानकारी हो। प्याकेट खस्दा समयसीमा हुन्छ: ग्राहक फेरि प्रयास गर्छ, केही फर्कंदैन, र आदेश हार नमानेसम्म झुन्डिरहन्छ। अस्वीकारले इन्कार वा रिसेट उत्पन्न गर्छ: केहीले जवाफ दियो र होइन भन्यो। नसुन्ने सेवा होस्टमै अस्वीकार गर्छ, कुनै फायरवालविना।

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

बाटो एकै पटक पढ्नुहोस्

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

ip route get 10.20.4.15
ip -brief address show
wg show
sudo ipsec statusall

बाटोको आउटपुटले प्याकेट कुन इन्टरफेसबाट निस्कन्छ र कुन स्रोत ठेगाना बोक्छ भन्ने बताउँछ। त्यो इन्टरफेस टनेल नभई तपाईंको भौतिक नेटवर्क कार्ड हो भने, समस्या राउटिङमा वा टनेलको अनुमति दिइएका दायराहरूमा छ, र त्यो फायरवालको होइन, VPN कन्फिगरेसनको हो।

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

जवाफ दिने तहमा नीति पढ्नुहोस्

बाटो सही भएपछि, होस्टबाट बाहिरतिर नीतिमा हिँड्नुहोस् र काउन्टर चल्ने त्यो एउटै तह हेर्नुहोस्:

ss -ltn | grep ':443'
sudo nft list ruleset
sudo iptables -S INPUT
sudo ufw status verbose

सुनिरहेको सकेट नियमभन्दा फरक प्रश्नको जवाफ दिन्छ। पोर्टमा केही सुनिरहेको छैन भने, कर्नेलले जडान अस्वीकार गर्छ र कुनै इनबाउन्ड नियम सान्दर्भिक हुँदैन। सकेट छ र टाढाको ग्राहकबाट जडान समयसीमामा गयो भने, बाटोमा कतै फाल्ने काम भइरहेको छ, र नियमका काउन्टरले त्यो यहीँ हुन्छ कि भनेर बताउँछन्।

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

टनेल त्यहीँ सकिएमा गेटवेको निर्णय पढ्नुहोस्

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

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

गेटवे त्यो ठाउँ पनि हो जहाँ NAT वा मास्करेड नियमले वास्तविक स्रोत लुकाउन सक्छ। आन्तरिक होस्टले ग्राहकको सट्टा गेटवेको ठेगाना देखे भने, ग्राहक पूलसँग मिल्नुपर्ने तिनका होस्ट फायरवाल नियम कहिल्यै मिल्दैनन्, र उपाय हरेक सर्भरमा होइन, गेटवेमा छ।

सबैभन्दा साँघुरो तह बदल्नुहोस्, त्यसपछि प्रमाणित गर्नुहोस्

फराकिलो मर्मतको विरोध गर्नुहोस्। होस्ट फायरवाल बन्द गर्नु, सबैलाई अनुमति दिने नियम थप्नु, वा हरेक इन्टरफेसलाई विश्वसनीय प्रोफाइलमा धकेल्नु — हरेकले आफ्नो काम गरिरहेको नियन्त्रण हटाउँछ, र परिवर्तन घटनापछि पनि रहन्छ। स्रोत दायरा र सम्बन्धित पोर्टमा सीमित नियम समीक्षा गर्न सजिलो, हटाउन सजिलो, र मेसिनको बाँकी नीति अक्षत राख्छ।

असफल भएको त्यही परीक्षणले, त्यही ग्राहकबाट प्रमाणित गर्नुहोस्, र फेरि जोडिएपछि एक पटक अझै, किनकि टनेलले फेरि वार्ता गर्नुअघि मिल्ने नियम पछि नमिल्न सक्छ:

nc -vz 10.20.4.15 443
curl -v --max-time 5 https://10.20.4.15/

त्यो बन्द गर्नुअघि:

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