तपाईंको स्प्लिट-टनेल नियम सेवासँग मिल्न किन रोकियो

स्प्लिट टनेलिङ सामान्यतया दुईमध्ये एक तरिकाले असफल हुन्छ। कि त टनेलभित्र हुनुपर्ने ट्राफिक यसलाई छलेर जान्छ, वा बाहिर रहनुपर्ने ट्राफिक भित्र तानिन्छ। पुरानो नियमको असफलता पहिलो प्रकार हो, र यो बढी भ्रमित गर्ने हो, किनकि नियम लेखिएको ठीक त्यसै गरी लागू गरिन्छ। जे परिवर्तन भयो त्यो गन्तव्य हो: सेवा अब नियमले कहिल्यै नाम नराखेको ठेगानामा जवाफ दिन्छ, र टनेलमा केही पनि गलत छैन।

नियमले के पिन गर्छ र 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 ले आफ्नै कन्फिगरेसनलाई अनियमित रूपमा बेवास्ता गर्यो भन्ने निष्कर्षमा पुग्नबाट रोक्छ।