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 संदर्भ क्रमबद्ध मार्गाचे दस्तऐवजीकरण करतो, म्हणून जुळणाऱ्या अंतिम नकाराखाली असलेली परवानगी पॅकेट कधीही वाचवत नाही। यापूर्वी स्वीकारलेले कनेक्शन नव्यापेक्षा वेगळे वागू शकते, त्यामुळे जुने यश नव्या नियमाबद्दल काहीच सांगत नाही। परवानगी चुकीची आहे असे गृहीत धरण्यापूर्वी तुमच्या परवानगीच्या वरचा नकार किंवा ड्रॉप शोधा। प्रत्येक नियमाचे काउंटर कोणत्या नियमाने पॅकेट पाहिले हेही सांगतात।

काय होते हे पाहण्यासाठी नियम हटवणे हा बदल आहे, निरीक्षण नाही। काउंटर वाचा, नियम क्रमांक नोंदवा, आणि मूळ धोरण बदल नोंदीत ठेवा। चाचणी टाळता येत नसेल, तर ती साखळीच्या प्रतीवर चालवा।

ज्या नियमावर त्याचा मालक नियंत्रण ठेवतो तो नियम बदला

फक्त इच्छित स्रोत आणि सेवा धोरण अद्ययावत करा, ज्याच्याकडे ते आहे त्याच्यामार्फत। सामायिक भाषांतरित निर्गम एकाच वेळी अनेक वापरकर्त्यांचे प्रतिनिधित्व करू शकते, त्यामुळे त्या पत्त्याला परवानगी देणे कोणाचीही पडताळणी करत नाही, आणि त्यामागील अ‍ॅप परवानग्या जिथे आहेत तिथेच राहतात।

पत्ता सरकत राहिल्यास, टिकाऊ उत्तर म्हणजे लांबलचक अपवाद यादी नव्हे, तर स्थिर निर्गम किंवा पडताळलेला मार्ग। निरीक्षण केलेला स्रोत, गंतव्य पोर्ट आणि नियम क्रमांक नोंदवा।