तुमच्या वेब सर्व्हरवरील VPN क्लायंट त्याची उत्तरे तोडतो का?

साइट त्याच नेटवर्कवरील लॅपटॉपवरून लोड होते आणि इतर सर्व ठिकाणांहून वेळ संपते, आणि होस्ट स्वतःच्या आउटबाउंड रहदारीसाठी VPN क्लायंटही चालवतो। हे संयोजन एक विशिष्ट बिघाड निर्माण करते: इनबाउंड कनेक्शन येते, उत्तर चुकीच्या मार्गाने बाहेर पडते, आणि बाहेरच्या क्लायंटला कधीही उत्तर दिसत नाही। दोन्ही अर्धे एकाच पॅकेट कॅप्चरमध्ये दिसतात, म्हणून घटनांचा क्रम हा वाचण्यासारखा भाग आहे.

स्रोत-आधारित राउट नियम अनेकदा लक्षण दूर करतो। तो सहसा ज्या साइटने त्याला कारणीभूत केले तिच्यापेक्षा जास्त रहदारीलाही सूट देतो, आणि नियम जतन करण्यापूर्वी समजून घेण्यासारखा भाग तोच आहे.

लक्षण: तो स्थानिक पातळीवर उत्तर देतो आणि बाहेरून नाही

नेटवर्कच्या आत उत्तराला बोगदा ओलांडण्याची गरज नसते, म्हणून पृष्ठ लोड होते आणि सेवा निरोगी दिसते। बाहेरून विनंती होस्टपर्यंत पोहोचते आणि उत्तर VPN मध्ये राउट होते, जिथे दूरच्या टोकाला ते स्वीकारण्याचे कोणतेही कारण नाही। ब्राउझरला नकाराऐवजी वेळ संपल्याचे दिसते, हे बंद पोर्टचे नाही तर एकमार्गी मार्गाचे लक्षण आहे.

राउटिंग बदलण्यापूर्वी आकाराची पुष्टी करा: श्रोता सुरू आहे, स्थानिक विनंती यशस्वी होते, आणि बाह्य विनंती कोणतेही उत्तर देत नाही। ही तीन निरीक्षणे एकत्रितपणे वेब सर्व्हर कॉन्फिगरेशनकडे नाही तर परतण्याच्या मार्गाकडे निर्देश करतात। इतकी स्वच्छ असममिती कोणत्याही लॉग ओळीपेक्षा उपयुक्त आहे, कारण ती एकही त्रुटी संदेश वाचण्यापूर्वी श्रोत्याला वगळते.

काम करताना स्वतंत्र प्रशासकीय मार्ग उघडा ठेवा। जो नियम तुमचे स्वतःचे SSH सत्र तोडतो तो दहा मिनिटांची दुरुस्ती प्रत्यक्ष भेटीत बदलतो.

स्रोत निवडकर्ता प्रत्यक्षात कशाशी जुळतो

Linux धोरण राउटिंगमध्ये, from 192.168.50.2 सारखा नियम ज्यांचा स्रोत तो पत्ता आहे अशा पॅकेटशी जुळतो। तो पॅकेट घरगुती राउटरमधून आलेल्या संभाषणाला पुढे चालू ठेवत आहे या वस्तुस्थितीचे कोडिंग करत नाही, आणि ते कोणत्या प्रक्रियेने तयार केले हे त्याला माहीत नाही। त्या उदाहरणातील पत्ता दृष्टांतासाठी आहे; तुमचा होस्ट प्रत्यक्षात वापरत असलेल्या पत्त्याने तो बदला। ओळीकडे पत्त्यांबद्दलचे विधान म्हणून पाहा आणि त्यापेक्षा अधिक काही नाही.

निवडलेला तक्ता सामान्य डीफॉल्ट मार्ग देत असल्यास, त्या स्रोतासह प्रत्येक पॅकेट तोच अपवाद घेऊ शकते। त्याच पत्त्याशी बांधलेली दुसरी सेवा तो वारसाहक्काने घेते, आणि जे अनुप्रयोग जाणूनबुजून त्या पत्त्याशी बांधतात तेही तो घेतात। धोरण नियम संदर्भ स्रोत, गंतव्य, प्रोटोकॉल, पोर्ट, खूण आणि प्राधान्य यांची स्वतंत्र निवडकर्ते म्हणून यादी करतो, जे केवळ स्रोत हाच उपलब्ध सर्वात ढोबळ पर्याय आहे याची आठवण करून देतो.

प्राधान्य निकाल ठरवते। शोध क्रमाने चालतात आणि निकाल देणारा पहिला तक्ता शोध संपवू शकतो, म्हणून खूप लवकर ठेवलेला नियम नंतरचा तक्ता दिला असता तो अधिक विशिष्ट मार्ग लपवू शकतो। तुम्ही जोडलेली एकच ओळ नाही तर संपूर्ण क्रमवार यादी वाचा। जो नियम कधीही जुळत नाही त्याचा काही खर्च नाही, तर खूप लवकर जुळणारा नियम त्याच्या मागील सर्व काही शांतपणे बदलतो.

परतण्याचा मार्ग आणि तुम्ही न मनात असलेली रहदारी तपासा

नियम आणि तक्ते वाचा, नंतर कर्नेलला विचारा की विशिष्ट स्रोत आणि गंतव्य जोडी कोणता मार्ग घेईल। होस्टवरूनच चाचणी करणे बाहेरून चाचणी करण्यासारखे नाही, म्हणून दोन्ही करा.

ip rule show
ip route show table 100
ip route get 203.0.113.44 from 192.168.50.2
ss -ltnp '( sport = :443 )'

नंतर नवीन बाह्य कनेक्शन स्वीकारा आणि स्वतंत्रपणे अशी विनंती जी अजूनही VPN मधून बाहेर पडली पाहिजे। दुसरी आता थेट बाहेर पडत असल्यास, अपवाद तुम्ही सोडवत असलेल्या समस्येपेक्षा रुंद आहे, आणि महत्त्वाची चाचणी ती आहे जी तुम्ही बदलण्याचा विचार केला नव्हता.

ब्राउझरमधील सार्वजनिक पत्ता तपासणी केवळ त्या ब्राउझरने केलेल्या विनंत्यांची माहिती देते। ती वेब सर्व्हरच्या उत्तरांबद्दल, दुसऱ्या स्थानिक अनुप्रयोगाच्या स्रोत निवडीबद्दल, किंवा पुढील VPN पुनर्जोडणीनंतर व्यवस्थापन रहदारीचे काय होते याबद्दल काहीही सांगत नाही.

अपवाद किती अरुंद असू शकतो ते ठरवा

दोन रचना रक्षणीय आहेत आणि त्या जाणूनबुजून निवडल्या पाहिजेत। होस्ट ही सेवा प्रकाशित करण्यासाठीच असल्यास आणि त्याची आउटबाउंड रहदारी महत्त्वाची नसल्यास, केवळ WAN धोरणासह समर्पित स्थानिक पत्ता ही वाजवी व्यवस्था आहे, जर तुम्ही संपूर्ण व्याप्ती स्वीकारली। केवळ विशिष्ट इनबाउंड कनेक्शन पात्र असावीत असे असल्यास, पत्ता निवड खूप ढोबळ आहे आणि त्यापूर्वी कनेक्शन-जाणीव रचना असावी.

तुम्ही ज्या करारावर विसंबून आहात तो नोंदवा: सार्वजनिक मॅपिंग, विनंती ज्या होस्ट पत्त्यावर पोहोचवली जाते तो पत्ता, आणि उत्तराने घ्यायचा मार्ग। VPN प्रदात्यामार्फत प्रकाशित इनबाउंड सेवा घरगुती राउटरमार्फत प्रकाशित केलेल्यापेक्षा वेगळा करार आहे, आणि एका उदाहरणातून नकल केलेला अपवाद दुसऱ्यासाठी अनेकदा चुकीचा असतो.

आदेश स्टार्टअप फाइलमध्ये पेस्ट करण्याऐवजी राउटिंगचा मालक असलेल्या घटकात धोरण ठेवा। नियमांचा क्रम, नेटवर्क बदलल्यानंतरची स्वच्छता आणि रीबूटनंतरची पुनरावृत्ती सर्वांनी टिकून राहिले पाहिजे, आणि न तपासलेली स्टार्टअप फाइल सहसा तुम्ही पाहत नसतानाच्या क्षणी अयशस्वी होते। तुम्ही रक्षण करू शकता अशा स्वीकृती निकालाने समाप्त करा: एक प्रकाशित साइट पुनर्संचयित आणि एक असंबंधित प्रवाह अपरिवर्तित.