IPsec गेटवेवरून पिंग वेगळा स्रोत पत्ता वापरतो

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

पिंग उत्तर देऊ शकणारे तीन वेगळे प्रश्न

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

आधी प्रश्न निवडा। नाहीतर अपयशी पिंग तुमच्याकडे आधीच असलेल्या सिद्धांताचा पुरावा बनतो।

गेटवे तुम्ही अपेक्षा न केलेला पत्ता का निवडतो

तुम्ही एखाद्या गंतव्यस्थानावर पिंग करता तेव्हा स्थानिक स्टॅक त्याला जुळणाऱ्या मार्गातून स्रोत निवडतो। मार्गाधारित बोगद्यात तो बोगदा इंटरफेसचा लिंक पत्ता असू शकतो, जो अनेक साइट आराखड्यांमध्ये पॉइंट-टू-पॉइंट हॉपसाठी निवडलेली 169.254.x.x जोडी असते। ते पत्ते लिंक चालण्यासाठी असतात; पलीकडे ते अनुप्रयोग-स्रोत नेटवर्क म्हणून जाहीर केले जात नाहीत।

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

स्रोत हेतुपुरस्सर निवडा

नियंत्रित Linux गेटवेवर आधीच स्थानिकपणे नेमून दिलेला स्रोत निवडा: ping -c 4 -I 10.30.0.1 10.40.0.20। येथील पत्ते उदाहरणादाखल आहेत, म्हणून गेटवेचा खरा आतील पत्ता आणि खरे दूरचे गंतव्य टाका, आणि तुम्ही निवडलेला स्रोत याच उपकरणाचा आहे आणि साइट धोरण त्याला परवानगी देते याची खात्री करा।

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

फक्त विनंती नाही, परतीचा मार्ग वाचा

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

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

मग वर्कलोडची चाचणी करा

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

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

फक्त एक निदान उत्तर मिळवण्यासाठी 169.254.0.0/16 साठी सर्वसमावेशक मार्ग जोडू नका। ते दिशाभूल करणाऱ्या चाचणीची कायमस्वरूपी मार्गनिर्देशन निर्णयाशी अदलाबदल करते, आणि पुढची व्यक्ती तो संदर्भाशिवाय वारसा म्हणून घेते।