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 ઓળખ બદલે છે, અને સરખામણી સફળ થાય તે માટે પ્રમાણપત્ર ચકાસણી બંધ કરવી એ નિદાન નથી.