VPN चा पिंग चालतो पण वेबसाइट अडकते: आकार तपासा

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

सर्वात लहान प्रश्नापासून सर्वात मोठ्या प्रश्नापर्यंत जा, आणि प्रत्येक पायरीने प्रत्यक्षात काय सिद्ध केले ते लिहा।

इको प्रतिसाद खूपच लहान प्रश्नाचे उत्तर देतो

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

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

कनेक्शन सुरू झाले का ते शोधा

लगेच नाकारलेले कनेक्शन हे श्रोता किंवा धोरणाचे उत्तर असते: काहीतरी उत्तर दिले आणि नाही म्हणाले। उघडून नंतर डेटा हलू लागल्यावर अडकणारे कनेक्शन आकाराकडे निर्देश करते। हँडशेक कधीच पूर्ण न करणारे कनेक्शन सामान्यतः धोरण किंवा मार्गनिर्देशनाचा प्रश्न असतो, आणि नकारापेक्षा वेळ संपल्यासारखे दिसते।

curl -v --max-time 10 https://internal.example/ -o /dev/null
ss -tn state established '( dport = :443 )'

MTU सेटिंग्जना हात लावण्यापूर्वी त्या तीनपैकी कोणती स्थिती पाहिली ते लिहा। नाकारलेले कनेक्शन सुधारण्यासाठी टनेलचा आकार बदलणे तो बदल वाया घालवते आणि खरे कारण काही काळ लपवते।

सांगितलेल्या संख्येने आकार मोजा

जेव्हा भाराखाली अडकणे दिसते, तेव्हा तुकडे न करण्याचा बिट लावून एक पॅकेट आकार तपासा आणि निकालाला अर्थ राहावा म्हणून गणित सांगा। iputils असलेल्या Linux वर, 1392 बाइटचा पेलोड आणि 8 बाइटचे ICMP शीर्ष तसेच 20 बाइटचे IPv4 शीर्ष मिळून तंतोतंत 1420 बाइटचे आंतरिक पॅकेट तयार होते। ते गणित तिकिटात लिहा, कारण गेटवेपर्यंत पोहोचणारा नुसता ping ॲप्लिकेशनबद्दल काहीही सिद्ध करत नाही।

ping -4 -M do -s 1392 10.44.0.10
ping -4 -M do -s 1372 10.44.0.10

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

बाहेरील मार्गाचा हिशेब करा

एन्कॅप्स्युलेशन स्वतःची शीर्षे जोडते, म्हणून तारेवरील पॅकेट टनेलमध्ये मोजलेल्या पॅकेटपेक्षा मोठे असते। या दोन्हींमधील फरकामुळेच एकाच वेळी चालणारी छोटी विनंती आणि अपयशी होणारी मोठी विनंती शक्य होते।

IPv4 मध्ये मार्ग MTU शोध विभाजनाशिवाय पुढे पाठवता न येणाऱ्या पॅकेटबद्दलच्या अभिप्रायावर अवलंबून आहे, आणि IPv6 Packet Too Big संदेश वापरते। IPv4 तपशील ती यंत्रणा वर्णन करतो। अभिप्राय गाळल्यास पाठवणाऱ्याची शिकण्याची क्षमता तुटते, आणि कधीच न बसणारे पॅकेट तो पुन्हा पुन्हा पाठवत राहतो। म्हणूनच चालणारी छोटी विनंती आणि अपयशी होणारी मोठी विनंती एवढ्या सहजतेने एकत्र राहतात।

एक संख्या बदला आणि ॲप्लिकेशन पुन्हा तपासा

टनेलचे MTU कमी करा, किंवा TCP साठी कमाल विभाग आकार मर्यादित करा, नंतर चाचणीऐवजी मूळ ॲप्लिकेशन चाचणी पुन्हा करा। बदलानंतर यशस्वी होणारी चाचणी आणि तरीही अडकणारे ॲप्लिकेशन ही सारख्याच आकाराची वेगळी समस्या आहे, आणि फक्त ॲप्लिकेशन चाचणीच त्यांच्यात फरक करते।

बदलाच्या नोंदीत गणित ठेवा: मोजलेला आकार, तुम्ही गृहीत धरलेला अतिरिक्त भार, आणि तुम्ही सेट केलेले मूल्य। नंतर त्याचा आढावा घेणारा कोणीही ping च्या स्क्रीनशॉटवरून गृहीतक पुन्हा काढण्याऐवजी ते तपासू शकतो।

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