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 क्लाइंट अब लेखकों में से एक नहीं है। अगर लिंक ऊपर आने के कुछ सेकंड बाद कोई मान पीछे सरक जाए, तो कोई और चीज़ अब भी कॉन्फ़िगरेशन लागू कर रही है, और अगला कदम दूसरा फ़्लैग जोड़ना नहीं बल्कि उस घटक की पहचान करना है। आप जो अंतिम स्थिति चाहते हैं वह घटना-रहित है: एक मालिक, एक दस्तावेज़ित नीति, और एक डिस्कनेक्ट होस्ट जो टनल के अस्तित्व से पहले की तरह ठीक वैसे ही हल करता है।