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

सकेट या त बाँधिएको छ या छैन

सक्रिय भएको रिपोर्ट गर्ने सेवा अझै पनि तपाईंले कहिल्यै नचाहेको ठेगाना वा यातायातमा बाँधिएको हुन सक्छ। सकेटलाई नै सोध्नुहोस्: ss -lunp UDP श्रोताहरू सूचीबद्ध गर्छ र ss -ltnp TCP, र पढ्न योग्य स्तम्भ स्थानीय ठेगाना हो, स्थिति होइन।

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

ss -lunp | grep 1194
ss -ltnp | grep 1194

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

बाहिरी प्याकेट क्याप्चर गर्नुहोस्, सुरुङ होइन

भौतिक इन्टरफेस र वास्तविक पोर्टमा फिल्टर गर्नुहोस्, आफ्नो इन्टरफेस राखेर: tcpdump -ni eth0 udp port 1194। फर्केर केही नआउने बाहिर जाने प्याकेटले माथि बसेको कुरातर्फ संकेत गर्छ: प्रदायक फिल्टरिङ, NAT उपकरण, वा तपाईं सोचेभन्दा फरक टाढाको ठेगाना। दुवै दिशामा मौनता क्लाइन्ट राउटिङ वा स्थानीय फायरवालतर्फ संकेत गर्छ। सुरुङको प्रगति बिना आउने उत्तरहरू नियन्त्रण च्यानलतर्फ संकेत गर्छन्, अर्थात् कुञ्जी वा साइफरको बेमेल, फिल्टरिङतर्फ होइन।

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

पहिले काउन्टर, ट्रेस जब तिनीहरू झूट बोल्छन्

काउन्टरबाट सुरु गर्नुहोस्, किनकि तिनीहरूको कुनै खर्च छैन। या त nft list ruleset वा iptables -L -n -v यहाँ महत्त्वपूर्ण एकमात्र प्रश्नको उत्तर दिन्छ: नियम मिल्यो? क्रमले नतिजा निर्धारण गर्छ, किनकि पहिलो मेल जित्छ, त्यसैले पछिको ACCEPT अघि फराकिलो DROP ले त्यो ACCEPT मृत छोड्छ र त्यसैले नियम थप्नु यति विरलै केही सुधार्छ।

स्वामित्वले पनि मानिसहरूलाई ठक्कर दिन्छ। कर्नेलले स्थानीय रूपमा उत्पन्न प्याकेटलाई सकेट खोलेको प्रक्रियासँग जोड्छ, र OpenVPN सामान्यतया root का रूपमा चल्छ, त्यसैले साधारण प्रयोगकर्ता ID मा बाँधिएको नियमले सुरुङको आफ्नै ट्राफिक कहिल्यै देख्दैन। नियम गलत छ भनेर निर्णय गर्नु अघि मालिक UID जाँच्नुहोस्।

काउन्टर अस्पष्ट रहेपछि मात्र लग हल्लाको योग्य हुन्छ, र त्यसपछि पनि साँघुरो भागका लागि मात्र: दर सीमित गर्ने र आफ्ना लग लाइनहरूमा उपसर्ग थप्ने iptables नियम, वा nft monitor trace चलिरहेको बेला meta nftrace set 1 बोकेको nftables नियम। ट्रेसले प्याकेट स्वीकार गरेको वा छोडेको चेन र नियमको नाम भन्छ। पछि दुवै हटाउनुहोस् र पेलोड लगिङ बाहिर राख्नुहोस्।

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

राउटिङ र फर्कने बाटो

स्वीकार गरिएको प्याकेट जो अझै हराउँछ, त्यसको गन्तव्य बाटो जाँच्नु आवश्यक छ। ip route get एउटा ठेगानाका लागि छानिएको रुट रिपोर्ट गर्छ, र उल्टो बाटोको फिल्टरिङले मुख्य तालिकाले कहिल्यै नछान्ने इन्टरफेसबाट आउने उत्तर छोड्न सक्छ। लक्षण ठ्याक्कै फायरवालले छोडेजस्तै देखिन्छ, त्यसैले यो जाँच अर्को NAT नियम अघि आउँछ।

गेटवेमा input चेनको सट्टा फर्वार्डिङ र forward चेन जाँच्नुहोस्। त्यसपछि टाढाको पक्षले स्रोत ठेगानामा कसरी पुग्ने जान्छ भनी पुष्टि गर्नुहोस्, किनकि काम गर्ने बाहिर जाने बाटोमा केही फर्किएन भने दुवै अवस्थामा मौनता हुन्छ।

अभिलेखले के भन्नुपर्छ

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

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

सम्बन्धित लेखहरू