VPN जोडले आहे पण एक सेवा अयशस्वी: टप्पा वेगळा करा

VPN तिकिटातील «जोडलेले» ही सर्वात कमी माहिती देणारी गोष्ट आहे। दोन बाजूंनी हॅंडशेक पूर्ण केला हे ते नोंदवते, आणि विचारलेले नाव, पॅकेट ज्या इंटरफेसातून बाहेर पडले, त्याचा आकार, किंवा दूरच्या टोकाने ते स्वीकारले का—यापैकी काहीही सांगत नाही। म्हणूनच एकाच लॅपटॉपवरील इतर सर्व अनुप्रयोग चालू असतानाही एक सेवा अयशस्वी होऊ शकते। टप्पे क्रमाने पार करा आणि पहिला अयशस्वी टप्पा दोषाचे नाव देईल।

नावाने सुरुवात करा, बोगद्याने नाही

मार्ग ठरवण्यापूर्वी सोडवा, कारण वाईट उत्तर पुढील प्रत्येक चाचणी निरर्थक करते। सिस्टम रिझॉल्व्हरकडे नाव विचारा आणि त्या उत्तराची तुलना अनुप्रयोगाने प्रत्यक्षात वापरलेल्या पत्त्याशी करा। खाजगी नाव सार्वजनिक पत्ता म्हणून परत आले म्हणजे ती चौकशी उत्तर देण्याचे काम नसलेल्या रिझॉल्व्हरकडे गेली। जे नाव सुटत नाही तेही त्याच श्रेणीतले आहे, फक्त जास्त मोठ्या आवाजात।

resolvectl query host.internal
getent hosts host.internal

स्वतःच्या सुरक्षित-DNS सेटिंग असलेले ब्राउझर येथे अयशस्वी होतात, बाकी सिस्टम चालू असते। म्हणूनच केवळ ब्राउझरशी संबंधित तक्रार प्रथम याच टप्प्यात येते, कोणीही मार्गाला हात लावण्यापूर्वी। एक नाही, दोन्ही आदेशांची तुलना करा, कारण getent NSS मार्ग अनुसरते आणि रिझॉल्व्हर चौकशी नाही।

कर्नेलला विचारा की त्याने कोणता मार्ग निवडला

राउटिंग तक्ता हा प्राधान्यक्रम आहे, आणि कर्नेल निवडतो तो मार्ग नेहमी आकृतीत दाखवलेलाच नसतो। संबंधित गंतव्याबद्दल त्याला थेट विचारा। उत्तर इंटरफेस, पुढील हॉप आणि वापरला जाणारा स्रोत पत्ता सांगते। पॅकेट बोगद्यातून दूरचे टोक नाकारते अशा स्रोत पत्त्यासह बाहेर पडू शकते, आणि भौतिक तक्त्यातील अधिक विशिष्ट नोंद त्याऐवजी Wi-Fi इंटरफेसातून पाठवू शकते।

ip route get 10.20.30.40
ip -brief address show

dev, via आणि src फील्ड्स याच क्रमाने वाचा, कारण प्रत्येक वेगळी शंका दूर करते। हा टप्पा क्लायंटने स्थापित केलेल्या स्थितीचाही स्वामी आहे, कारण फायरवॉल नियम आणि मार्ग असामान्य निर्गमानंतरही राहू शकतात। म्हणूनच «बोगद्याशिवाय इंटरनेट नाही» आणि «क्लायंट न चालल्यास इंटरनेट नाही» दोन नाही, एकच दोष-कुटुंब आहेत।

पॅकेटचा आकार तपासा

मोठे स्थानांतरण अडकत असताना परत येणारे छोटे उत्तर प्रथम मार्गाच्या MTU कडे इशारा करते। बोगद्याच्या आतून पाठवलेली, do-not-fragment बिट सेट केलेली एक प्रोब या टप्प्याला इतरांपासून वेगळे करते। प्रोब अयशस्वी होईपर्यंत पेलोड वाढवा आणि तुमच्याकडे महत्त्वाचा आकडा असेल।

ping -M do -s 1400 10.20.30.40

डिरेक्टरी सूची किंवा अपलोड अडकलेले असताना छोट्या प्रोब पास होणे ही या टप्प्याची खूण आहे। तक्रार लॉगिन माहिती किंवा फायरवॉल नियमासारखी वाटते, आणि ती दोन्हीपैकी कोणतीही नाही।

हा आकडा क्लायंटचा नाही, मार्गाचा गुणधर्म आहे, म्हणून ऑफिस कनेक्शनवर चालणारे मूल्य मोबाइल लिंकवर अयशस्वी होऊ शकते। प्रोब आदेश तिकिटासोबत ठेवा, कारण पुढच्या व्यक्तीला तेच माप हवे असते। लहान पेलोड पास झाल्यास उपाय clamp किंवा कमी बोगदा MTU आहे, नवीन सायफर नाही।

दूरच्या टोकाची चाचणी करा

गंतव्याची त्याच्या पत्त्याने चाचणी करा, मग तिथे काय ऐकत आहे ते पाहा। नाकारलेले कनेक्शन आणि कधीही उत्तर न देणारे कनेक्शन या वेगळ्या निष्कर्ष आहेत। पहिले सांगते की काहीतरी चालू आहे आणि ते पोर्ट सेवा देत नाही, आणि दुसरे सांगते की काहीही परत आले नाही। डीफॉल्टनुसार दोन्हीपैकी कोणतेही क्लायंटची समस्या नाही।

curl -sv http://10.20.30.41:8080/health
nc -vz -w 3 10.20.30.41 3389
ss -lnt 'sport = :8080'

बोगद्यातून पोहोचणारी कोणतीही गोष्ट केवळ 127.0.0.1 वर ऐकणारी सेवा असू शकत नाही, कारण श्रोता पॅकेट कधीही पाहत नाही। जेव्हा दूरच्या होस्टचा फायरवॉल ऑफिस सबनेटला परवानगी देतो आणि बोगदा पूल नाकारतो, तेव्हा निकाल क्लायंटचा दोष वाटतो आणि तो नसतो। वेब रहदारी टिकून असताना Remote Desktop किंवा फाइल शेअरिंग तुटणे सहसा येथेच येते, वापरकर्ता कसेही म्हणो।

तक्रारीची एका टप्प्याशी जोडणी करा

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

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

पहिली अयशस्वीता निर्माण करणारा टप्पा आदेशाच्या आउटपुटसह नोंदवा। स्रोत पत्ता चुकीचा होता असे सांगणारे आणि मार्गाची ओळ जोडलेले तिकीट कारवाईस पात्र आहे, तर VPN तुटलेला आहे असे नोंदवणारे तिकीट नाही।