कुन लिङ्कले जवाफ दिन्छ: स्प्लिट-टनेल VPN DNS का लागि राउटिङ डोमेनहरू

सामान्य ब्राउजिङ स्थानीय लिङ्कमा राख्नुहोस्, जबकि कम्पनीका नामहरू टनेलले दिने DNS सर्भरमार्फत हल हुन्छन्। VPN को पूर्वनिर्धारित रुट बन्द गर्दा पहिलो आधा भाग पाइन्छ र दोस्रो आधा नबनेको रहन्छ। अब आउँछ हराएको सेटिङ, त्यसको अर्थ बदल्ने विरामचिन्ह, र कुन लिङ्कले वास्तवमै जवाफ दियो भनेर देखाउने एउटै आदेश। सम्पूर्ण पाठमा NetworkManager र systemd-resolved मानिएका छन्, किनकि अलमल सामान्यतया यही जोडीबाट सुरु हुन्छ।

पहिलो चरण: रुटलाई रिजोल्भरबाट अलग गर्नुहोस्

ipv4.never-default राउटिङको प्रश्नको जवाफ दिन्छ र NetworkManager लाई यो जडान सबै IPv4 ट्राफिकको बाटोको रूपमा स्थापना गर्नबाट रोक्छ। DNS राउटिङ डोमेनले अर्को प्रश्नको जवाफ दिन्छ: मिल्ने सफिक्सका लागि कुन लिङ्कका नाम सर्भरहरूले क्वेरी पाउँछन्। कुनैले पनि अर्कोलाई जनाउँदैन, र प्रोफाइलले वर्षौंसम्म एउटा बोक्न सक्छ जबकि अर्को हराइरहेको हुन्छ। रुट मात्र भन्नाले टनेलले कम्पनीका सबनेट बोक्छ र यसको रिजोल्भरले कम्पनीका नामहरूको जवाफ दिन्छ, बाँकी सबै छोइएको हुँदैन।

रुट प्रोपर्टी मात्र सेट गर्नुहोस् त भित्री नामहरू असफल हुन्छन्, सामान्यतया भाँचिएको टनेलजस्तो सुनिने टाइमआउटसँग। डोमेन मात्र सेट गर्नुहोस् त मेसिनका हरेक छोटो नाममा चुपचाप खोजी सफिक्स थप्नुभएको छ। दुवै गल्तीले टिकट VPN सर्भरमा पठाउँछन्, जो विरलै गलत भाग हुन्छ।

दोस्रो चरण: प्रोफाइलमा राउटिङ-मात्र डोमेन थप्नुहोस्

जडानको नाम corp-vpn छ, कम्पनीको सफिक्स internal.example हो, र टनेलको रिजोल्भर पहिले नै पुग्न सकिने छ भनी मान्नुहोस्। पहिले हालका मानहरू पढ्नुहोस्, किनकि तलका आदेशहरूले पहिले नै प्रविष्टि हुन सक्ने प्रोपर्टीहरू बदल्छन्।

nmcli connection show corp-vpn | grep -E 'dns-search|never-default'
nmcli connection modify corp-vpn +ipv4.dns-search '~internal.example'
nmcli connection modify corp-vpn ipv4.never-default yes

आफ्नै जडान नाम र सफिक्सले प्रतिस्थापन गर्नुहोस्, किनकि माथिका मानहरू उदाहरण हुन्। प्लस चिन्ह देखिनेभन्दा बढी महत्त्वपूर्ण छ: यससँग मान विद्यमान सूचीमा थपिन्छ, यसबिना प्रोपर्टी प्रतिस्थापन हुन्छ र हिजो काम गरेको प्रोफाइलबाट असम्बन्धित डोमेनहरू गायब हुन्छन्। टिल्डाले शैली नभई व्यवहार बदल्छ, र तलको अनुच्छेदले यसले के छान्छ भन्ने व्याख्या गर्छ। लेख्नुअघि पढ्ने क्रम राख्नुहोस्, ताकि प्रतिस्थापन रूपले तपाईंलाई कहिल्यै चकित नपारोस्।

सुरुको टिल्डाले राउटिङ-मात्र डोमेन जनाउँछ, त्यसैले मिल्ने क्वेरीहरू यो लिङ्कका सर्भरहरूमा जान्छन् र सफिक्स छोटो नाममा थपिँदैन। टिल्डा हटाउनुभयो भने त्यही स्ट्रिङ खोजी सफिक्स पनि बन्छ, जो मानिसहरूले विरलै चाहने फरक परिणाम हो। माथिका दुवै सेटिङ IPv4 हुन्, त्यसैले दोहोरो-स्ट्याक प्रोफाइललाई ipv6.never-default र ipv6.dns-search मा त्यही राउटिङ डोमेन चाहिन्छ, नत्र IPv6 पक्षले पूर्वनिर्धारित रुट प्रयोग गरिरहन्छ र त्यहाँ भित्री नामहरू असफल हुन्छन्।

तेस्रो चरण: कुन लिङ्कले जवाफ दियो भनेर resolvectl लाई सोध्नुहोस्

resolvectl status चलाउनुहोस् र हरेक लिङ्कका DNS सर्भर र डोमेन पढ्नुहोस्, त्यसपछि सोध्न अनुमति भएको वास्तविक भित्री नाममा resolvectl query host.internal.example चलाउनुहोस्। दोस्रो आदेश नै राउटिङ डोमेनले आफ्नो काम गरिरहेको एउटै प्रत्यक्ष प्रमाण हो, किनकि यसले जवाफ दिने लिङ्कको नाम लिन्छ। स्थिति सूची मात्रले कन्फिगरेसन प्रमाणित गर्छ; क्वेरीले हल प्रमाणित गर्छ।

systemd-resolved सबैभन्दा राम्रो मिल्ने राउटिङ डोमेन छान्छ, त्यसैले अर्को लिङ्कको थप विशिष्ट डोमेनले अझै दौड जित्न सक्छ। क्वेरी अपेक्षा नगरेको लिङ्कबाट फर्कियो भने, VPN को DNS सर्भर छुनुअघि डोमेन सूचीहरू पढ्नुहोस्। ~. मूल डोमेन सबैसँग मिल्छ, र पहिले नै छ भने तपाईंको विशिष्ट डोमेन आफ्नै नामका लागि अझै जित्छ जबकि लिङ्कले तपाईंले सोधेभन्दा धेरैलाई जवाफ दिन्छ। उद्देश्य कम्पनीका नाम मात्र भएको बेला त्यो मूल प्रविष्टि हटाउनुहोस् वा साँघुरो बनाउनुहोस्।

VPN लिङ्कले कुनै DNS सर्भर सूचीबद्ध गर्दैन भने, क्लाइन्टले कहिल्यै दर्ता गरेन। पछाडि सर्भर नभएको राउटिङ डोमेन हराएको डोमेनभन्दा फरक तरिकाले असफल हुन्छ, त्यसैले पहिले दर्ता सुधार्नुहोस्।

चौथो चरण: नाम हल हुन्छ तर सेवा हुँदैन

सही जवाफले हल भएको मात्र प्रमाणित गर्छ, र एप्लिकेसनलाई अझै पाएको ठेगानासम्म रुट चाहिन्छ। त्यो रुटले भर्खर कन्फिगर गरेको विभाजित पूर्वनिर्धारितबाट जोगिनुपर्छ, त्यसैले DNS लाई फेरि दोष दिनुअघि जाँच्नुहोस्। त्यसपछि सेवाको पोर्टमा पहुँच जाँच्नुहोस्, किनकि फाइल साझेदारी वा डाइरेक्टरी सेवा हल, राउटिङ वा प्रमाणीकरणमा असफल हुन्छ र हरेक अवस्थामा लगभग उस्तै सन्देश दिन्छ। नतिजा रिपोर्ट गर्दा यी तीन तह अलग राख्नुहोस्, नत्र अर्को व्यक्तिले पहिले नै सही भएको DNS फेरि जाँच्छ।

यो प्रश्नसँगै घुम्ने Samba परिवर्तन पहुँच तहको हो, DNS छनोटको होइन। नाम-हल त्रुटिमा त्यसलाई लागू गर्नु नै सानो समस्याले दोस्रो पाउने बाटो हो।

पाँचौं चरण: हराएको डोमेन सुधार्न रिजोल्भर नबदल्नुहोस्

रिजोल्भर फाइलमाथि लेख्ने वा अर्को रिजोल्भर म्यानेजर स्थापना गर्ने सल्लाहले अर्को समस्या समाधान गर्छ। ती आफ्नै असफलता ढाँचा भएका प्रणाली-एकीकरण परिवर्तन हुन्, र तीमध्ये कुनैले पनि कहिल्यै कन्फिगर नगरिएको राउटिङ डोमेन थप्दैन। बदल्नुअघि मेसिनमा नाम-हल कुन कम्पोनेन्टको हो निश्चित गर्नुहोस्, किनकि systemd-resolved भएको NetworkManager डेस्कटपमा त्यो स्वामित्व पहिले नै परिभाषित छ। त्यससँग लड्नु नै काम गर्ने सेटअपलाई कसैले पुनः सिर्जना गर्न नसक्ने कुरा बनाउने बाटो हो।

कामको क्रम: टनेलले रिजोल्भर दिन्छ भनी पुष्टि गर्नुहोस्, राउटिङ-मात्र डोमेन थप्नुहोस्, प्रोफाइल नियन्त्रणबाट फेरि जोडिनुहोस्, जवाफ दिने लिङ्क प्रमाणित गर्नुहोस्, र त्यसपछि सेवालाई यसको पोर्टमा परीक्षण गर्नुहोस्। यो क्रमले दोस्रो अन्तर्वार्ताबिना अर्को व्यक्तिलाई दिन सकिने नतिजा छोड्छ।