VPN मधून ping: प्रतिध्वनी उत्तराचे नियम परतीचा मार्ग का चुकवतात

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

पॅकेट पोर्ट नाही, प्रकार बदलते

प्रतिध्वनी विनंती ICMP प्रकार 8, कोड 0 आहे, आणि ती ओळखकर्ता व क्रमांक घेऊन जाते। उत्तर प्रकार 0, कोड 0 आहे, त्याच ओळखकर्ता व क्रमासह, आणि IP टोके बदललेली आहेत। ही क्षेत्रे RFC 792 परिभाषित करते, आणि ओळखकर्ताच प्रेषकाला उत्तरे त्याच्या स्वतःच्या विनंत्यांशी जुळवण्याची परवानगी देतो।

जे नाही तेही तितकेच महत्त्वाचे: TCP किंवा UDP हेडर नाही, म्हणून परवानगी देण्यासाठी पोर्ट नाही। प्रतिध्वनी उत्तरासाठी पोर्ट नेमणारा नियम असा पॅकेट वर्णन करतो जो कधीही अस्तित्वात येणार नाही। VPN ping तिकिटांतील ही सर्वात सामान्य चूक आहे। नियम ठोस दिसतो, कशालाच लागू होत नाही, आणि बिघाड जिथे होता तिथेच ठेवतो।

पॅकेटविषयी तीन संदर्भ निर्णय घेतात

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

या तीन संदर्भांना वेगवेगळ्या नियम-शृंखला आणि वेगवेगळे काउंटर आहेत, आणि त्यांना एक मानणे हेच «फायरवॉल ICMP ला परवानगी देतो» असे असूनही ping अपयशी होण्याचे कारण आहे। बाह्य बोगदा हा चौथा संदर्भ आहे: VPN श्रोत्याला परवानगी देणे डीकॅप्स्युलेट झालेल्या आतील विनंतीला स्वयंचलितपणे परवानगी देत नाही, आणि आतील परवानगी बाह्य बोगदा सुरू आहे की नाही याबद्दल काहीही सांगत नाही।

स्टेटफुल आणि स्टेटलेस फिल्टर उत्तर वेगळ्या पद्धतीने हाताळतात

विनंती बाहेर जाताना पाहिलेला स्टेटफुल फायरवॉल उत्तर त्या प्रवाहाशी जोडून दुसऱ्या नियमाशिवाय प्रवेश देऊ शकतो। स्टेटलेस फिल्टरकडे अशी स्मृती नसते, म्हणून परतीच्या दिशेला स्वतःची स्पष्ट परवानगी लागते, स्रोत व लक्ष्य उलटून।

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

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

भाषांतर ओळखकर्ताही बदलते

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

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

ICMP त्रुटी प्रतिध्वनी धोरणात विलीन करू नका

मार्गाच्या MTU शोधात वापरला जाणारा «तुकडे करणे आवश्यक» संदेश प्रतिध्वनी उत्तर नाही, आणि त्याचा पेलोड तो उद्भववणारे पॅकेट उद्धृत करतो। केवळ प्रतिध्वनीला परवानगी देणारा नियम त्या त्रुटी शांतपणे टाकून देतो तेव्हा आकाराची समस्या लटकत्या जोडणीत बदलते, जे उपयुक्ततेच्या विरुद्ध आहे।

तीच सावधानी पत्ता कुटुंबांनाही लागू होते। ICMPv6 वेगळे संदेश प्रकार वापरते आणि IPv4 मध्ये नसलेली आवश्यक कार्ये वाहून नेते, म्हणून हे क्रमांक IPv6 नियमात नकलणे सरळ चूक आहे।

प्रतिध्वनीची देवघेव चालली तर खरे अनुप्रयोग वेगळे तपासा। यशस्वी ping एका प्रोटोकॉलची एका आकारात एका लक्ष्यापर्यंतची येरझार सिद्ध करते, आणि HTTPS, SMB किंवा अन्य कोणताही प्रवाह परवानगीप्राप्त आहे असे गृहीत धरण्याचा तो परवाना नाही।