तुमचा स्प्लिट-टनेल नियम एखाद्या सेवेशी जुळणे का थांबले

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

नियम काय पिन करतो आणि DNS काय परत देतो

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

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

जुळणी तुटण्याचे तीन मार्ग

स्पष्ट प्रकरण म्हणजे स्थलांतरित सेवा: ऑपरेटरने तिला नवीन पत्ता दिला, DNS मागे आले, आणि अपवाद मागे आला नाही। दुसरा म्हणजे नियमाने कधीही व्यापले न केलेला पत्ता कुटुंब, जे तेव्हा घडते जेव्हा नाव फक्त IPv4 साठीचा अपवाद दुर्लक्षित करतो असे AAAA रेकॉर्ड परत देऊ लागते। तिसरा resolver फरक आहे: अंतर्गत आणि सार्वजनिक दृश्य एकाच नावासाठी वेगवेगळे पत्ते परत देऊ शकतात, म्हणून तुमचे ॲप वापरत असलेला पत्ता तुम्ही चाचणी केलेला पत्ता नाही।

कॅश केलेले कनेक्शन चौथा प्रकार आहे आणि ते चुकवणे सोपे आहे। ॲप अजूनही तासभरापूर्वी सोडवलेल्या पत्त्याशी बोलत असू शकते, याचा अर्थ तुमचा ताजा शोध आणि त्याचे उघडे socket सेवा कुठे आहे यावर एकमत नाहीत।

ॲप प्रत्यक्षात वापरत असलेले गंतव्य वाचा

ब्राउझर टॅबला नाही, ऑपरेटिंग सिस्टम आणि socket तक्त्याला विचारा। शोध नाव सध्या कशात सोडवले जाते ते सांगतो, आणि socket तक्ता प्रक्रिया ज्या पत्त्याशी जोडलेली आहे तो दाखवतो, जो जुना असू शकतो। सिद्धांत मांडण्यापूर्वी दोन्ही चालवा, कारण त्यांच्यातील फरक सुमारे अर्ध्या प्रकरणांमध्ये स्वतःच उत्तर असतो।

getent ahosts api.example.com
dig +short api.example.com A
dig +short api.example.com AAAA
ss -tnp | grep -F api
ip route get 203.0.113.40

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

लक्षण नाही, यंत्रणा दुरुस्त करा

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

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

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

हेतूच्या दोन्ही अर्ध्या भागांची पडताळणी करा

स्प्लिट-टनेल रचनेचे दोन हेतू असतात, आणि दुरुस्तीने दोन्ही टिकवले पाहिजेत। संरक्षित सेवेने टनेलमधून जावे, आणि वगळलेल्या श्रेणींनी त्याला वळसा घालणे सुरू ठेवावे। दुरुस्त केलेल्या गंतव्याशी नवीन कनेक्शन तपासा, नंतर बाहेर राहिले पाहिजे अशी एखादी गोष्ट तपासा।

curl -sv --max-time 5 https://api.example.com/ -o /dev/null 2>&1 | grep -E 'Trying|Connected to'
curl -sS --max-time 5 https://public.example/ -o /dev/null -w '%{http_code}\n'

नवीन पत्ता, निवडलेली यंत्रणा आणि तारीख नोंदवा। तीच नोंद पुढच्या व्यक्तीला VPN ने स्वतःचे कॉन्फिगरेशन यादृच्छिकपणे दुर्लक्षित केले असा निष्कर्ष काढण्यापासून थांबवते।