VPN चा DNS प्रत्येक लुकअप घेतो: NetworkManager मधील dns-priority दुरुस्त करा
VPN कनेक्शन डीफॉल्टने प्राधान्य 0 ठेवते आणि प्रत्येक डोमेनचा दावा करते। क्रमासाठी ऋणात्मक प्राधान्य सेट करा, नंतर उर्वरित परत देण्यासाठी राउटिंग डोमेन वापरा।
ऑफिसच्या VPN ला जोडा आणि अचानक प्रत्येक नाव लुकअप कॉर्पोरेट रिझॉल्व्हरकडे जाते। सार्वजनिक नावे अजूनही सुटतात, त्यामुळे स्थानिक प्रिंटरचे नाव अयशस्वी होईपर्यंत किंवा split-horizon रेकॉर्ड ऑफिसचा पत्ता परत देईपर्यंत काहीही तुटलेले दिसत नाही। काही Fedora सेटअपमध्ये उलटे घडते: बोगदा वर आल्यानंतरही ISP रिझॉल्व्हर उत्तर देत राहतो। दोन्ही एकच प्रश्न आहेत — ही क्वेरी कोणत्या रिझॉल्व्हरच्या मालकीची आहे — आणि NetworkManager प्रणालींमध्ये उत्तर प्रत्येक कनेक्शनच्या DNS गुणधर्मांमध्ये असते।
दोन कनेक्शन, एक जिंकणारा रिझॉल्व्हर
प्रत्येक कनेक्शन DNS प्राधान्य घोषित करते। सामान्य कनेक्शन डीफॉल्टने 50 वर आणि VPN कनेक्शन 0 वर असतात, आणि कमी मूल्य जिंकते। हेच डीफॉल्ट कारण आहे की VPN कनेक्शन दावा केलेल्या प्रत्येक डोमेनसाठी तारेच्या लिंकला शांतपणे मागे टाकते: कोणीही न निवडताही शून्य पन्नासला हरवते।
प्राधान्य उमेदवारांचा क्रम ठरवते। विजेत्याला कशाबद्दल विचारायचे हे ते मर्यादित करत नाही। शोध डोमेन नसलेले VPN कनेक्शन सर्व काही दावा करते, त्यामुळे त्याला प्राधान्य दिल्यास सार्वजनिक क्वेरीही बोगद्यात जातात आणि स्प्लिट-बोगदा रचनेत कॉर्पोरेट रिझॉल्व्हर जिथे फॉरवर्ड करते तिथेही जातात।
प्राधान्य क्रम ठरवते, शोध यादी मालकी ठरवते
nmcli -f connection.id,ipv4.dns,ipv4.dns-search,ipv4.dns-priority con show "Corp VPN"
resolvectl status
readlink -f /etc/resolv.conf
शोध यादी ही मालकीची घोषणा आहे। corp.example सारखे नग्न डोमेन शोध प्रत्यय आणि राउटिंग डोमेन बनते। फक्त-राउटिंग स्वरूप ~corp.example त्या प्रत्ययाखालील लुकअप डोमेन लहान नावांमध्ये न जोडता या कनेक्शनवर पाठवते। ती टिल्डा «या सर्व्हरला विचारा» आणि «या सर्व्हरला विचारा आणि माझे टायपिंग पूर्ण करा» यातील फरक आहे।
वापरकर्ते लहान होस्टनावे टाइप करतात आणि रेकॉर्ड पूर्णपणे पात्र नावांनीही संबोधले जातात तेव्हा दोन्ही स्वरूप वापरा। रिझॉल्व्हर नग्न नाव कसे पूर्ण करते हे न बदलता विभाजन हवे असेल तेव्हा फक्त राउटिंग स्वरूप वापरा।
मग प्राधान्य स्पष्ट करा आणि पुन्हा सक्रिय करा:
nmcli con modify "Corp VPN" ipv4.dns-priority -100
nmcli con modify "Corp VPN" ipv6.dns-priority -100
nmcli con modify "Corp VPN" ipv4.dns-search "~corp.example,corp.example"
nmcli con up "Corp VPN"
ऋणात्मक प्राधान्य म्हणजे «या कनेक्शनला प्राधान्य दे» असे म्हणण्याचा दस्तऐवजीत मार्ग, आणि दोन्ही पत्ता कुटुंबे सेट केल्यास IPv6 कनेक्टिव्हिटी असलेल्या होस्टवर वर्तन एकसमान राहते। कनेक्शन पुन्हा सक्रिय न करता गुणधर्म बदलल्यास आता चालू असलेल्या कशातही बदल होत नाही, म्हणून क्रम स्पष्ट up ने संपतो।
विभाजन systemd-resolved कडे ठेवा
डीफॉल्ट dnsmasq प्लगइन क्वेरी एका स्थानिक रिझॉल्व्हरमध्ये ओतते, त्यामुळे प्रति-लिंक विभाजन ढोबळ राहते। systemd-resolved प्रत्येक लिंकसाठी विभाजन दाखवते, आणि resolvectl query उत्तर दिलेल्या लिंकचे नाव सांगते।
systemctl enable --now systemd-resolved
ln -sf /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf
systemctl restart systemd-resolved NetworkManager
resolvectl query build.corp.example
त्यानंतर कॉर्पोरेट लिंक corp.example वाहून नेते आणि सार्वजनिक रिझॉल्व्हर उर्वरित सेवा देतो। क्वेरी चुकीच्या लिंकवर पोहोचल्यास आदेश तिला उत्तर दिलेल्या लिंकचे नाव सांगतो, आणि ते जाणणे फक्त पत्ता जाणण्यापेक्षा चांगले आहे।
DNS रचना बोगद्याच्या प्रकाराशी जुळवा
सर्व काही बोगद्यातून पाठवणाऱ्या गोपनीयता रचनांनी विभाजन यादी ठेवू नये, कारण ती सार्वजनिक नावे स्थानिक रिझॉल्व्हरला परत देईल आणि हेतू रद्द करेल। स्प्लिट-बोगदा रचनांना ती आवश्यक आहे: ती नसल्यास कॉर्पोरेट रिझॉल्व्हर प्रत्येक सार्वजनिक क्वेरी पाहतो, आणि बोगदा पडताच सेटअप तुटतो।
मग बोगद्याबाहेरील DNS अडवणारा kill switch आहे। बोगद्याच्या झोनसाठी नावे सुटतात आणि बाकी सर्वत्र अयशस्वी होतात, तर कनेक्शन पूर्णपणे निरोगी असते। व्यवहार्य उत्तरे म्हणजे LAN रिझॉल्व्हरसाठी स्पष्ट परवानगी किंवा फक्त कॉर्पोरेट झोन फॉरवर्ड करणारी स्थानिक कॅश, आणि दोन्हीपैकी कोणतेही बोगद्यातील दोष नसून मालक असलेला अपवाद आहे।
इंटरफेस सुरू होताना रिझॉल्व्हर संरचना पुन्हा लिहिणारी प्रोफाइलही जवळजवळ तसेच वागते: स्थानिक रिझॉल्व्हर पोहोचाबाहेर गेल्यावर बोगद्याला माहीत असलेली नावेच सुटतील। कोणतीही यंत्रणा लागू असो, प्रत्येक स्थितीत कोणती नावे काम करायला हवीत ते लिहून ठेवा, आणि ती यादी अहवाल हाताळणाऱ्याला द्या।
प्रत्येक लिंकवर तपासा, नंतर पुन्हा जोडल्यावर पुन्हा तपासा
एक अंतर्गत आणि एक सार्वजनिक नाव विचारा, आणि क्वेरी प्रत्यक्षात कुठे जाते ते पाहा। गळती-तपासणी पृष्ठ कोणत्या रिझॉल्व्हरने उत्तर दिले ते सांगते, सिस्टमने कोणती लिंक निवडली ते नाही, त्यामुळे तुम्ही नुकतीच सेट केलेल्या क्रमाबद्दल ते काहीही सांगत नाही।
डिस्कनेक्ट आणि पुन्हा कनेक्ट केल्यानंतर दोन्ही क्वेरी पुन्हा चालवा। कनेक्शन सक्रिय झाल्यावर प्राधान्ये पुन्हा लागू होतात, आणि जुनी सिम्बॉलिक लिंक कोणालाच आठवत नसलेल्या अपग्रेडमधूनही टिकू शकते। शेवटी तुम्हाला लिहून ठेवायचे आहे ते म्हणजे कोणता रिझॉल्व्हर कोणत्या प्रत्ययाचा मालक आहे, शिवाय उद्याही वैध राहणारी तपासणी।