VPN ठेगाना स्वीकृत सूचीमा राख्यो तर अझै अवरुद्ध? यसको पदचिह्न पत्ता लगाउनुहोस्

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

सेवासम्म पुग्ने अनुरोधबाट सुरु गर्नुहोस्। सुरुङ ठेगाना, निकास ठेगाना र तिनीहरूबीचको कुनै पनि अनुवाद गन्तव्यले तीमध्ये एक पुष्टि नगरेसम्म परिकल्पना नै रहन्छ।

एपमा देखिने ठेगाना पुग्ने ठेगाना होइन

VPN जडानले कम्तीमा चार ठेगाना बोक्छ, जसलाई छुट्टाछुट्टै नाम दिन लायक छ: सर्भरको अन्तिम बिन्दु, तपाईंको क्लाइन्टलाई दिइएको भित्री सुरुङ ठेगाना, स्थानीय Wi-Fi वा Ethernet ठेगाना, र ट्राफिक प्रदायकबाट बाहिरिएपछि वेबसाइटले देख्ने सार्वजनिक ठेगाना। क्लाइन्ट विन्डोले दोस्रो मात्र देखाउन सक्छ। नियमको नाम राख्नुअघि चारैको नाम राख्नुहोस्। विभाजित सुरुङमा, सार्वजनिक गन्तव्यका अनुरोधले सुरुङ पूरै छल्न सक्छन्, त्यसैले असफल सत्र प्रयोगकर्ताले सुरु गरेको भन्ने ठानेको सत्र होइन।

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

एउटा अनुरोधलाई यसको फिल्टरिङ सीमासम्म पछ्याउनुहोस्

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

अधिकृत Linux होस्टमा, परिवर्तन गर्नुअघि सक्रिय नियमहरू क्रममा पढ्नुहोस्। फर्वार्ड गरिएका र कन्टेनर सेवाहरू प्रायः आफ्नै चेनमा हाम्फाल्छन्, त्यसैले हाम्फाल्ने लक्ष्य र अन्तिम फैसला दुवै जाँच्नुहोस्।

iptables -vnL INPUT --line-numbers
iptables -S INPUT | head -n 40
ss -ltnp | grep -E ':(443|9443)\b'

टिकटमा मिल्ने नियम नम्बर उल्लेख गर्नुहोस्। त्यो बिना अर्को पाठकले कुन सम्पादनले नतिजा बदल्यो भन्ने जान्न सक्दैन। समयछाप नभएको नियम नम्बर अझै अस्पष्ट छ।

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

एउटा हानिरहित अनुरोध र एउटा साँघुरो क्याप्चरले बारम्बार फर्किने प्रश्न टुंग्याउँछ। गन्तव्य पोर्ट र अनुसन्धानमा रहेको होस्टमा फिल्टर गर्नुहोस्, प्याकेट संख्या सीमित गर्नुहोस्, र अनुरोध पूरा हुनासाथ क्याप्चर रोक्नुहोस्।

tcpdump -ni any 'tcp dst port 9443' -c 20

तीन मान छेउछाउमा तुलना गर्नुहोस्: क्याप्चरमा रहेको स्रोत, मिल्ने नियमले उल्लेख गर्ने स्रोत, र एपले अभिलेख गरेको अस्वीकृति। यी सबै फरक हुन सक्छन्, र IP नियमले निर्धारण गरेको खसाइ पहिलोले मात्र व्याख्या गर्छ। फर्वार्ड गरिएको HTTP हेडर प्रोक्सी तहको हो, त्यसैले त्यो हेडर उद्धृत गर्ने लगले फायरवालले मूल्याङ्कन गरेको स्रोत वर्णन गर्दैन।

नियम मात्र होइन, चेनको क्रम पढ्नुहोस्

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

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

जुन नियमलाई यसको मालिकले नियन्त्रण गर्छ त्यो बदल्नुहोस्

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

ठेगाना सर्दै रहँदा, टिकाउ उत्तर लामो अपवाद सूची होइन, स्थिर निकास वा प्रमाणित च्यानल हो। अवलोकन गरिएको स्रोत, गन्तव्य पोर्ट र नियम नम्बर अभिलेख गर्नुहोस्।