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 संदर्भ क्रमबद्ध पारगमन का दस्तावेज़ीकरण करता है, इसीलिए मेल खाने वाली अंतिम अस्वीकृति के नीचे बैठी अनुमति कभी पैकेट को नहीं बचाती। पहले स्वीकार किया गया कनेक्शन नए से भिन्न व्यवहार कर सकता है, इसलिए पुरानी सफलता नए नियम के बारे में कुछ नहीं कहती। अनुमति को गलत मानने से पहले अपनी अनुमति के ऊपर अस्वीकृति या गिरावट खोजें। प्रति-नियम काउंटर भी बताते हैं कि किस नियम ने पैकेट देखा।

क्या होता है यह देखने के लिए नियम हटाना एक परिवर्तन है, अवलोकन नहीं। काउंटर पढ़ें, नियम नंबर नोट करें, और मूल नीति को परिवर्तन रिकॉर्ड में रखें। यदि परीक्षण अपरिहार्य है, तो इसे श्रृंखला की प्रति पर चलाएँ।

वह नियम बदलें जिसे उसका स्वामी नियंत्रित करता है

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

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