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 क्लायंट आता लेखकांपैकी एक नाही. दुवा वर आल्यानंतर काही सेकंदांनी मूल्य मागे सरकल्यास, दुसरे काहीतरी अजूनही संरचना लागू करत आहे, आणि पुढील पाऊल आणखी एक फ्लॅग जोडणे नाही तर तो घटक ओळखणे आहे. तुम्हाला हवी असलेली अंतिम स्थिती घटनारहित आहे: एक मालक, एक दस्तऐवजीकृत धोरण, आणि बोगदा अस्तित्वात येण्यापूर्वीप्रमाणेच नेमके रिझॉल्व्ह करणारा डिस्कनेक्ट झालेला होस्ट.