OpenVPN कनेक्ट होता है पर कुछ नहीं बहता: वह परत खोजें जहाँ पैकेट गिरता है

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 नियम जो दर सीमित करता है और अपनी लॉग पंक्तियों में उपसर्ग जोड़ता है, या nftables नियम जो meta nftrace set 1 लिए रहता है जबकि nft monitor trace चल रहा हो। ट्रेस उस श्रृंखला और नियम का नाम बताता है जिसने पैकेट स्वीकार या गिराया। बाद में दोनों हटा दें और पेलोड लॉगिंग बाहर रखें।

परिवहन भी जाँचें। TCP तक सीमित फ़ायरवॉल सेवा उस संख्या पर UDP श्रोता के बारे में कुछ नहीं कहती, इसलिए सही पढ़ा गया नियम भी हर पैकेट गिरा सकता है।

रूटिंग और वापसी का रास्ता

स्वीकृत पैकेट जो फिर भी गायब हो जाता है, उसके गंतव्य पथ की जाँच चाहिए। ip route get एक पते के लिए चुना गया रूट बताता है, और उलटे पथ की फ़िल्टरिंग ऐसे इंटरफ़ेस से आने वाला उत्तर गिरा सकती है जिसे मुख्य तालिका कभी नहीं चुनती। लक्षण ठीक फ़ायरवॉल द्वारा गिराए जाने जैसा दिखता है, इसलिए यह जाँच दूसरे NAT नियम से पहले आती है।

गेटवे पर input श्रृंखला के बजाय फ़ॉरवर्डिंग और forward श्रृंखला जाँचें। फिर पुष्टि करें कि दूरस्थ पक्ष जानता है कि स्रोत पते तक कैसे पहुँचना है, क्योंकि काम करता बाहरी पथ जब कुछ वापस न आए तो दोनों ही स्थितियों में मौन है।

रिकॉर्ड को क्या कहना चाहिए

हर बदलाव के लिए, जाँचा गया चरण, पढ़ा गया साक्ष्य और उसके दोनों ओर काउंटर का मान लिखें। वही नोट "अब यह काम करता है" को अगली समीक्षा में टिकाऊ बनाता है।

दो शॉर्टकट नोट को ईमानदार रखते हैं। जो पैकेट होस्ट से कभी नहीं निकला वह कहीं और के नियम से गिराया नहीं जा सकता था, दूरस्थ पक्ष की कॉन्फ़िगरेशन कितनी भी विश्वसनीय दिखे। जो पैकेट निकला और लौटा वह प्रश्न को नेटवर्क परत के ऊपर ले जाता है, जहाँ फ़ायरवॉल काउंटरों के पास आपको बताने के लिए अब कुछ नहीं बचा है।