VPN क्लायंट कनेक्ट होताच वेब सर्व्हर गायब होतो

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

लक्षण: विनंत्या आत, उत्तरे चुकीच्या दारातून बाहेर

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

उत्तर कुठे जाते हे पाहून याची पुष्टी करा, विनंती कशी येते हे पाहून नाही।

भौतिक इंटरफेसवर आणि टनेल उपकरणावर एकाच वेळी कॅप्चर करा। विनंती भौतिक इंटरफेसवर दिसली आणि उत्तर टनेलवर दिसले तर निदान पूर्ण झाले। कुठेही न दिसणारे उत्तर म्हणजे सेवेने कनेक्शन कधीच स्वीकारले नाही, ही वेगळ्या कारणाची वेगळी तपासणी आहे।

दोन डीफॉल्ट मार्ग आणि एक राउटिंग निर्णय

डीफॉल्ट मार्ग स्थापित करणारा क्लायंट LAN गेटवेपेक्षा चांगल्या मेट्रिकसह दुसरी नोंद जोडतो। काही क्लायंट त्याऐवजी अर्ध्या-श्रेणीचे दोन मार्ग स्थापित करतात, जे तीच जागा अधिक विशिष्टपणे व्यापतात आणि त्याच प्रकारे शोध जिंकतात। दोन्ही तंत्रे सामान्य बाहेर जाणाऱ्या पॅकेटला टनेल इंटरफेस निवडू देतात।

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

टनेल संपूर्ण वेळ योग्य वागतो। त्याला डीफॉल्ट मार्ग वाहून नेण्यास सांगितले होते आणि तो नेमके तेच करतो।

टनेल न तोडता परतीचा मार्ग दुरुस्त करा

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

होस्टने काय करावे यानुसार निवडा, तुम्हाला प्रथम कोणता तुकडा सापडला यानुसार नाही।

गंतव्यस्थान वगळणे स्थिर सार्वजनिक पत्ता असलेल्या सेवेसाठी योग्य आहे, आणि डीमनला प्रत्येक पत्त्याऐवजी भौतिक पत्त्याला बांधणे ते वगळणे अधिक सुरक्षित करते। स्रोतानुसार तक्ता निवडणारा धोरण नियम होस्टची स्वतःची कनेक्शन टनेलमध्ये ठेवतो आणि सेवेची उत्तरे WAN गेटवेमार्फत परत पाठवतो। WAN इंटरफेसवर उत्तरे मास्क करणे त्याच मार्गापर्यंत पोहोचते, पण सेवेच्या लॉगमधून क्लायंटचा पत्ता लपवण्याच्या किंमतीवर। डीफॉल्ट मार्गाचा तात्काळ बदल हे निदान आहे, संरचना नाही, कारण क्लायंट प्रत्येक पुनर्कनेक्शनला मार्ग पुन्हा लिहितो।

ip rule show
ip route get 203.0.113.9 from 192.0.2.44

जेव्हा होस्ट आपल्या मागील LAN साठीही राउट करतो

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

दोन बदल ते दुरुस्त करतात: आंतर्गामी कनेक्शन अंतर्गत उपकरणापर्यंत पोहोचण्यासाठी गंतव्य भाषांतर, आणि त्या उपकरणाचे उत्तर राउटरकडूनच आले असे वाटण्यासाठी स्रोत भाषांतर।

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