openfortivpn बारम्बार DNS लेख्दै छ? वास्तविक मालिक खोज्नुहोस्

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

तलको क्रमले क्लाइन्टलाई बाहिरतिर पछ्याउँछ: कनेक्सनले के बदल्यो, कुन स्विचले कुन लेखकलाई दबाउँछ, कसले जिम्मेवारी लिनुपर्छ, र नतिजा पुनः जडानमा टिक्छ भनेर कसरी पुष्टि गर्ने। प्रत्येक चरणले फरक चिन्ह छोड्छ, र त्यही चिन्हले हस्तान्तरण साँच्चै भयो कि भएन भनेर बताउँछ।

कनेक्सनले साँच्चै के बदल्यो त्यसबाट सुरु गर्नुहोस्

आफ्नो सामान्य आदेशले एक पटक जोड्नुहोस् र अघि र पछिको रिजोल्युसन तुलना गर्नुहोस्। systemd-resolved चलाउने Linux होस्टमा, resolvectl status ले प्रत्येक लिङ्कका लागि DNS सर्भर र खोज डोमेन छाप्छ, र आफ्नै सर्भर बोक्ने नयाँ tun वा ppp लिङ्क क्लाइन्ट-पक्षको अद्यावधिकको औंलाको छाप हो। macOS मा, scutil --dns ले रिजोल्भर कन्फिगरेसन त्यही क्रममा देखाउँछ जुन क्रममा अनुप्रयोगहरूले त्यसलाई सोध्छन्।

त्यसलाई तपाईंले बदलिने अपेक्षा गरेको फाइलसँग तुलना गर्नुहोस्। प्रति-लिङ्क दृश्यमा कनेक्सन-बद्ध प्रविष्टि र पुनः लेखिएको /etc/resolv.conf दुई फरक नतिजा हुन्, र दोस्रो पूर्ण रूपमा अरू केहीले व्यवस्थापन गर्ने साङ्केतिक लिङ्क हुन सक्छ। रिजोल्भरको ठेगाना, खोज डोमेन र इन्टरफेसको नाम एउटै क्षणमा लेख्नुहोस्; तीमध्ये कुनै पनि बदलिएमा फरक लेखकतिर सङ्केत गर्छ। त्यो आधाररेखा बिना, पछिको प्रत्येक सुधार तीन घटकमध्ये कुन सर्यो भन्ने अनुमान मात्र हो।

दुई स्विच र प्रत्येकले शान्त गराउने लेखक

openfortivpn ले आफूले नियन्त्रण गर्न सक्ने दुवै लेखक बन्द गर्ने विकल्प-टुक्राको कागजात गर्छ, र प्रत्येक स्विचसँग म्यानुअलले एउटै सेटिङ मान्ने पूरै लेखिएको समतुल्य रूप छ।

openfortivpn gw.example.com:443 --no-dns --pppd-no-peerdns
# written out in long form
openfortivpn gw.example.com:443 --set-dns=0 --pppd-use-peerdns=0

--no-dns ले क्लाइन्टलाई गेटवेबाट सिकेका DNS सर्भर लागू गर्नबाट रोक्छ, जबकि --pppd-no-peerdns ले pppd लाई साथीको DNS प्रणालीमा धकेल्नबाट रोक्छ। upstream म्यानुअल ले PPP मार्फत हुने DNS अद्यावधिक क्लाइन्टका आफ्नै DNS अद्यावधिकसँग प्रतिस्पर्धा गर्न सक्ने चेतावनी दिन्छ, त्यसैले दुईमध्ये एउटालाई पर्याप्त मान्नुको सट्टा दुवै स्विच टुक्रामा हुनुपर्छ।

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

केही अक्षम गर्नुअघि मालिक छान्नुहोस्

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

मार्गको स्वामित्व जानाजान छुट्टै रहन्छ. मार्ग विकल्पहरू आवश्यक छैनन् किनकि तपाईंले DNS बदल्नुभयो, र विकल्प नराखी मार्ग स्थापना बन्द गर्दा तपाईंले भर्खरै छानेको रिजोल्भर पुग्न नसकिने हुन सक्छ। राउटिङ तालिकामा विशेष गरी रिजोल्भरको ठेगानाका लागि हेर्नुहोस्, तपाईंले संयोगवश परीक्षण गरेको अनुप्रयोग उपजालका लागि मात्र होइन।

रिजोल्युसन प्रत्येक लिङ्कका लागि जाँच्नुहोस्, प्रत्येक फाइलका लागि होइन

सीमित वा प्रति-डोमेन रिजोल्युसन भएको होस्टमा अनुप्रयोगहरूले साँच्चै के प्रयोग गर्छन् भन्ने सूची एउटा /etc/resolv.conf होइन, त्यसैले प्लेटफर्मले रिजोल्भरको अवस्था खोलेको तरिकाले पढ्नुहोस्।

resolvectl status
resolvectl query vpn.internal.example.com
resolvectl query example.com
ip route get 10.20.0.53

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

फेरि जोड्नुहोस् र विच्छेदित अवस्था पुष्टि गर्नुहोस्

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

त्यसपछि फेरि जोड्नुहोस् र त्यही तीन मान पढ्नुहोस्: रिजोल्भरको ठेगाना, खोज डोमेन, इन्टरफेस।

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