DNS विफलता वा MTU समस्या? अनुरोध वास्तवमा कहाँ रोकिन्छ

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

दुई फरक तहमा दुई विफलता

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

लक्षणहरू कुनै पनि उपकरण बिना अवलोकन गर्न सकिने तरिकाले फरक पर्छन्। DNS विफलता तत्काल र स्थिर हुन्छ: ब्राउजरले सर्भर भेटिएन भन्छ। MTU विफलता आंशिक हुन्छ: पृष्ठ सुरु हुन्छ, केही स्रोत आउँछन्, र ठूलो प्रतिक्रिया वा अपलोड अड्किन्छ।

यदि तपाईंको लक्षण आंशिक छ भने, DNS हेर्न बन्द गर्नुहोस्।

चरण 1: नाम बिल्कुल समाधान हुन्छ कि

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

अपरेटिङ सिस्टमले प्रयोग गर्ने रिजोल्भरलाई सोध्नुहोस्, त्यसपछि तुलना गर्नुहोस्:

dig +short vpn.example.com
dig +short vpn.example.com @10.0.0.53

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

चरण 2: स्थानान्तरण कहाँ रोकिन्छ

यदि नाम समाधान भयो र जडान सुरु भयो भने, कार्य कहाँ रोकिन्छ त्यो अभिलेख गर्नुहोस्। देखाइएपछि एउटा स्रोतमा अड्किने पृष्ठ, स्थिर बिन्दुमा मर्ने अपलोड, वा साना अनुरोधहरू काम गरिरहेको बेला कहिल्यै नसकिने ठूलो डाउनलोड — सबै आकार-आकारका लक्षण हुन्। बिल्कुल सुरु नहुने प्रतिक्रियाको आकार फरक हुन्छ।

तुलना गर्दा अन्त्य बिन्दु र अनुप्रयोगको गन्तव्य स्थिर राख्नुहोस्, नत्र तपाईं एकैचोटि दुई चल मापन गर्दै हुनुहुन्छ। यो चरणमा अन्य कारणहरू पनि सम्भव छन्: सेवा त्रुटि, हानि, फिल्टरको व्यवहार र टनेलको पुनःजडान — सबैले अवरोध उत्पन्न गर्छन्।

दोहोर्याउन सकिने एउटा अवरोध दस किस्साभन्दा बढी मूल्यवान छ।

MTU ले ह्यान्डशेकपछि मात्र हानि किन गर्छ

TCP ह्यान्डशेक साना प्याकेट प्रयोग गर्छ, त्यसैले पूर्ण आकारको खण्ड बोक्न नसक्ने बाटोमा पनि सफल हुन्छ। विफलता तब देखिन्छ जब प्रेषकले खण्डीकरण-निषेध बिटसहित ठूलो प्याकेट पठाउँछ, लिङ्कले त्यो फाल्छ, र सीमा जनाउनुपर्ने ICMP सन्देश कहिल्यै पुग्दैन किनकि फिल्टरले त्यो खायो। त्यसपछि प्रेषकले त्यही आकार फेरि प्रयास गर्छ र स्थानान्तरण अड्किन्छ।

त्यसैले लक्षण अनियमित नभई आकारमा निर्भर र दोहोर्याउन सकिने हुन्छ। यसले होस्टलाई पिङ गर्नुले केही प्रमाणित नगर्ने कुरा पनि व्याख्या गर्छ, किनकि सानो ICMP प्रतिध्वनि पूर्ण आकारको भार नबोक्ने बाटो पार गर्न सक्छ। सम्भव भए बाटोका दुवै छेउबाट आकार मापन गर्नुहोस्। एटै दिशामा मात्र देखिने सीमा टनेलको MTU नभई राउटिङ असन्तुलन हो।

अनुमान गर्नुको सट्टा आकार स्पष्ट रूपमा मापन गर्नुहोस्:

ping -M do -s 1472 203.0.113.20
tracepath 203.0.113.20

एउटा तह बदल्नुहोस्, त्यसपछि प्रमाणित गर्नुहोस्

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

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

त्यही अभिलेखले DNS, प्याकेट आकार र प्रमाणीकरणलाई कसैले पनि व्याख्या गर्न नसक्ने स्थायी वैकल्पिक मार्गहरूको थुप्रो बन्नबाट रोक्छ। कच्चा IP बाट परीक्षण गर्नु TLS पहिचान बदल्ने छोटो बाटोको राम्रो उदाहरण हो, र तुलना सफल होस् भनेर प्रमाणपत्र प्रमाणीकरण बन्द गर्नु निदान होइन।