IPsec गेटवेबाट पिंगले फरक स्रोत ठेगाना प्रयोग गर्छ

IPsec गेटवेबाट पारिपट्टि पिंग गर्नुहोस्, जवाफ नपाएर सुरुङ भाँचिएको निष्कर्ष निकाल्नुहोस्, जबकि गेटवे पछाडिको हरेक कार्यभारले सामान्य रूपमा ट्राफिक पठाइरहेको हुन्छ। यी दुई नतिजा एकअर्काको विपरीत होइनन्। गेटवेमा सुरु गरिएको पिंग स्थानीय स्रोत भएको प्याकेट हो, र गेटवेले आफ्नै रुटिङ तालिकाबाट स्रोत ठेगाना छान्छ। त्यो छनोट साइटको वास्तविक ट्राफिकले प्रयोग गर्ने ठेगानाहरूभन्दा फरक हुन सक्छ, जसले कुन नीति मिल्छ र कुन फर्किने बाटो लागू हुन्छ भन्ने बदल्छ। नतिजाबाट केही पनि पढ्नु अघि परीक्षणले के प्रमाणित गर्नुपर्ने हो त्यो निर्धारण गर्नुहोस्।

पिंगले जवाफ दिन सक्ने तीन फरक प्रश्न

पहिलो प्रश्न यो हो कि यो होस्टबाट पारिपट्टि पुग्नै सकिन्छ कि सकिँदैन। दोस्रो यो हो कि सुरुङका सिलेक्टरहरू वा रुटमा आधारित नीतिले कुनै निश्चित स्रोतबाट आउने ट्राफिक स्वीकार गर्छ कि गर्दैन। तेस्रो यो हो कि गेटवे पछाडिको कार्यभारबाट अगाडि पठाइएको ट्राफिक छेउदेखि छेउसम्म चल्छ कि चल्दैन। एउटा आदेशले तीनैको जवाफ दिन सक्दैन, र तिनलाई छुट्याउने कुरा स्रोत ठेगाना हो।

पहिले प्रश्न छान्नुहोस्। नत्र असफल पिंग तपाईंसँग पहिले नै भएको सिद्धान्तको प्रमाण बन्छ।

गेटवेले किन तपाईंले नसोचेको ठेगाना छान्छ

तपाईंले कुनै गन्तव्यमा पिंग गर्दा स्थानीय स्ट्याकले त्यससँग मिल्ने रुटबाट स्रोत छान्छ। रुटमा आधारित सुरुङमा त्यो सुरुङ इन्टरफेसको लिङ्क ठेगाना हुन सक्छ, जो धेरै साइट डिजाइनमा बिन्दुदेखि बिन्दुसम्मको हपका लागि छानिएको 169.254.x.x जोडी हो। ती ठेगानाहरू लिङ्क चल्नका लागि हुन्छन्; पारिपट्टि तिनलाई अनुप्रयोग-स्रोत सञ्जालका रूपमा घोषणा गरिँदैन।

त्यसैले पारिपट्टिले फर्किने बाटो नभएको ठेगानाबाट, वा कुनै सिलेक्टरसँग नमिल्ने ठेगानाबाट प्रतिध्वनि अनुरोध पाउन सक्छ। सुरुङ स्वस्थ हुन सक्छ र पिंग तैपनि असफल हुन सक्छ, र यो लेखले भनेको ठ्याक्कै त्यही झुटो नकारात्मक नतिजा हो।

स्रोत जानाजान छान्नुहोस्

नियन्त्रित Linux गेटवेमा पहिले नै स्थानीय रूपमा तोकिएको स्रोत छान्नुहोस्: ping -c 4 -I 10.30.0.1 10.40.0.20। यहाँका ठेगानाहरू उदाहरणका लागि हुन्, त्यसैले गेटवेको वास्तविक भित्री ठेगाना र वास्तविक टाढाको गन्तव्य राख्नुहोस्, र तपाईंले छानेको स्रोत यही यन्त्रको हो र साइट नीतिले त्यसलाई अनुमति दिन्छ भनी पुष्टि गर्नुहोस्।

परीक्षणका लागि कुनै कार्यभारको ठेगाना सापटी नलिनुहोस्। गेटवेमा नतोकिएको होस्टको नक्कल गर्दा कसैले पनि दोहोर्याउन नसक्ने नतिजा बन्छ, र केही स्ट्याकमा यो सुरुङको खराबीजस्तै देखिने तरिकाले असफल हुन्छ।

अनुरोध मात्र होइन, फर्किने बाटो पनि पढ्नुहोस्

टाढाको गन्तव्यमा वास्तवमा कुन स्रोत पुग्छ भनी जाँच्नुहोस्, बाटोमा भएको कुनै जानाजानको अनुवादसमेत समेटेर। त्यसपछि पारिपट्टिको त्यो स्रोततर्फ फर्किने रुट र त्यसलाई अनुमति दिने सिलेक्टर वा नीति जाँच्नुहोस्। अप्रत्याशित स्रोतसँग आउने अनुरोध रुटिङ र नीतिको प्रश्न हो, क्रिप्टोग्राफीको होइन।

यहीँ अर्को पिंगभन्दा प्याकेट क्याप्चरले बढी मद्दत गर्छ: यसले पारिपट्टिले देखेको स्रोत देखाउँछ, र त्यसको जवाफ पुग्नुपर्ने ठेगाना त्यही हो।

त्यसपछि कार्यभार परीक्षण गर्नुहोस्

निर्णायक परीक्षण गेटवे पछाडिको सामान्य होस्टबाट टाढाको गेटवे पछाडिको सामान्य होस्टमा पिंग हो। यसले गेटवेको अगाडि पठाउने भूमिका, अनुप्रयोगको वास्तविक स्रोत र साँचो फर्किने बाटो परीक्षण गर्छ, र प्रयोगकर्तालाई चाहिने प्रवाह त्यही हो।

आफ्ना टिप्पणीमा नतिजा छुट्टै राख्नुहोस्: गेटवेबाट पहुँच, छानिएको स्रोतका लागि नीतिको अनुमति, र अगाडि पठाइएको ट्राफिक। सफलतापूर्वक पिन गरिएको पिंग सुरुङले केही बोक्छ भन्ने उपयोगी प्रमाण हो; हरेक अगाडि पठाइएको प्रवाह चल्छ भन्ने प्रमाण होइन। र पुग्न नसकिने स्वतः छानिएको गेटवे स्रोत साइटको सुरुङ बन्द छ भन्ने प्रमाण होइन।

केवल एउटा निदान जवाफ पाउनका लागि 169.254.0.0/16 का लागि व्यापक रुट नथप्नुहोस्। त्यसले भ्रममा पार्ने परीक्षणलाई स्थायी रुटिङ निर्णयसँग साट्छ, र अर्को व्यक्तिले त्यसलाई सन्दर्भबिना पाउँछ।