/etc/resolv.conf க்காக போட்டியிடும் இரண்டு Linux சேவைகளை நிறுத்துங்கள்

DNS திரும்பத் திரும்ப பழைய நிலைக்கே திரும்புகிறது, VPN மீண்டும் இணைவது உங்கள் திருத்தத்தை ரத்து செய்கிறது, இறுதியில் குழுவில் யாரோ கோப்பைப் பூட்டப் பரிந்துரைக்கிறார். அந்த வரிசை ஒரு அறிகுறி, தீர்வல்ல: இரு கூறுகளும் /etc/resolv.conf தங்களுடையது என்று நம்புகின்றன, கடைசியாக எழுதுபவரே வெற்றி பெறுகிறார். கோப்பைப் பூட்டுவது உரிமை முரண்பாட்டைத் தீர்க்காது, அதை மறைத்து அதே நேரத்தில் நீங்கள் உண்மையில் விரும்பிய கூறை உடைக்கிறது. கீழே உள்ள நான்கு சோதனைகளை வரிசையாகச் செய்து, கோப்பில் அல்ல, அதை உரிமை கொண்ட நிலையில் ஏற்பாட்டைச் சரிசெய்யுங்கள்.

சோதனை 1: இது குறியீட்டு இணைப்பா, எங்கே

கோப்பிலிருந்தே தொடங்குங்கள், ஏனெனில் நீங்கள் திருத்தும் பாதை கோப்பாகவே இருக்காது. தீர்ப்பான் ஒன்றின் இயக்கக் கோப்பகத்திற்குச் செல்லும் குறியீட்டு இணைப்பு, வாடிக்கையாளர் ஸ்கிரிப்ட் மீண்டும் எழுதும் சாதாரண கோப்பை விட முற்றிலும் வேறுபட்டு நடந்துகொள்ளும்:

ls -l /etc/resolv.conf
readlink -f /etc/resolv.conf
cat /etc/resolv.conf

systemd-resolved இன் stub பாதைக்கான இணைப்பு என்பது கோப்பின் உள்ளடக்கம் உருவாக்கப்படுகிறது என்பதாகும், கைமுறை திருத்தம் அடுத்த நிகழ்வில் மேலெழுதப்படும். nameserver வரிகளைக் கொண்ட சாதாரண கோப்பை பொதுவாக இணைக்கும்போது இயங்கும் வாடிக்கையாளர் அல்லது DHCP கொக்கி எழுதுகிறது. இரண்டும் செல்லுபடியானவை; எதையும் மாற்றும் முன் உங்களிடம் எது இருக்கிறது என்பதை அறிவதே முக்கியம்.

சோதனை 2: எந்த டீமன் இயங்குகிறது

எது நிறுவப்பட்டுள்ளது என்பதல்ல, எது உண்மையில் செயலில் உள்ளது என்பதைக் கண்டறியுங்கள். நவீன விநியோகத்தில் பல தீர்ப்பான்கள் இருக்கலாம், loopback இடைமுகத்தில் போர்ட் 53 வைத்திருப்பதே பதிலளிக்கிறது:

systemctl status systemd-resolved --no-pager
resolvectl status
ss -lunp | grep ':53'

நிலை வெளியீடு ஒவ்வொரு இணைப்பின் DNS சேவையகங்களையும் வழிமாற்று டொமைன்களையும் பெயரிடுகிறது, அதுவே split DNS க்கு உங்களுக்குத் தேவையான வரைபடம். உள் பெயர்கள் உள் சேவையகத்திற்கும் மற்ற அனைத்தும் பொது சேவையகத்திற்கும் செல்ல வேண்டும் என்றால், அந்தக் கொள்கை ஒவ்வொரு இணைப்பின் டொமைன்களில் வாழ்கிறது, அதைக் கோப்பில் நிலையான nameserver பட்டியலாகத் தட்டையாக்கினால் அந்த வேறுபாடு அமைதியாக இழக்கப்படுகிறது.

NetworkManager இன் சொந்த உள்ளமைவு இவற்றில் எந்த backend ஐப் பயன்படுத்துவது என்பதைத் தீர்மானிக்கிறது. முதன்மை உள்ளமைவுக் கோப்பில் அதன் dns= அமைப்பு அதன் உள் தீர்ப்பான், dnsmasq, systemd-resolved மற்றும் none இடையே தேர்ந்தெடுக்கிறது, விநியோகம் உங்களுக்காகத் தேர்ந்தெடுத்திருக்கலாம். இந்த ஹோஸ்ட்டில் “DNS சரிசெய்வது” என்பதன் பொருளைத் தீர்மானிக்கும் முன் அந்த அமைப்பைப் படியுங்கள்.

சோதனை 3: VPN வாடிக்கையாளர் எதை எழுத அனுமதிக்கப்படுகிறார்

முரண்பாடு பொதுவாக இங்கேயே வாழ்கிறது. தீர்ப்பான் கோப்பை நேரடியாக மீண்டும் எழுதும் VPN வாடிக்கையாளர் அதைப் பராமரிக்கும் எந்தச் சேவையுடனும் சண்டையிடும், தோற்பவர் முதலில் இயங்குபவர். புதிய OpenVPN வெளியீடுகள் கோப்பை மீண்டும் எழுதுவதற்குப் பதிலாக DNS அமைப்புகளை systemd-resolved க்கு வழங்கலாம், அதுவே நீங்கள் விரும்பும் ஒத்துழைப்பு நடத்தை; பழைய ஸ்கிரிப்ட்களும் கையால் எழுதப்பட்ட கொக்கிகளும் பெரும்பாலும் பழைய உதவிக் கருவியை அழைக்கின்றன அல்லது கோப்பின் மேல் எழுதிவிடுகின்றன.

WireGuard இன் நிலை வடிவில் ஒத்ததாக உள்ளது: இடைமுக உள்ளமைவே DNS ஐ நிர்வகிக்காது, அதைச் சுற்றியுள்ள கருவிகள் தீர்ப்பான் உதவியாளர் அல்லது resolved ஒருங்கிணைப்பு வழியாக நிர்வகிக்கின்றன. அத்தகைய இரண்டு உதவியாளர்கள் நிறுவப்பட்டிருந்தால், இரண்டும் இணைக்கும்போது தங்கள் உலகப் பார்வையைச் செயல்படுத்த முயலும்.

ஊகிப்பதற்குப் பதிலாக வாடிக்கையாளரின் up மற்றும் down கொக்கிகளைப் படியுங்கள். /etc/openvpn/up.sh அல்லது அதற்கு இணையான கோப்பகத்தில் உள்ள சில shell வரிகள் இல்லாவிட்டால் சீரற்றதாகத் தோன்றும் நடத்தையை விளக்குகின்றன, வாடிக்கையாளரைப் போட்டியிட வைப்பதற்குப் பதிலாக ஒத்துழைக்க வைக்கும் இடமும் அதுவே.

சோதனை 4: உரிமையாளரிடம் சரிசெய்யுங்கள், கோப்பில் அல்ல

உரிமையாளர் யார் எனத் தெரிந்ததும், அந்த உரிமையாளர் ஆதரிக்கும் இடைமுகம் வழியாக DNS ஐ உள்ளமைக்கவும். systemd-resolved க்கு இது நிலையான கோப்பிற்குப் பதிலாக ஒவ்வொரு இணைப்பின் அமைப்புகளும் வழிமாற்று டொமைன்களும் என்பதாகும்; NetworkManager க்கு இணைப்புச் சுயவிவரத்தின் DNS அமைப்புகளும் தேர்ந்தெடுக்கப்பட்ட backend உம்; resolvconf ஒருங்கிணைப்பைப் பயன்படுத்தும் விநியோகத்திற்கு அந்த உதவியாளர் வழியாக எழுதுவதும்.

கோப்பை மாற்றமுடியாததாக்க வேண்டாம். மாற்றமுடியாத பண்பு சட்டபூர்வமான DHCP புதுப்பித்தல்களையும் VPN புதுப்பிப்புகளையும் நீங்கள் போராடியவற்றுடன் சேர்த்து நிறுத்துகிறது, அடுத்த தொகுப்பு மேம்படுத்தல் அல்லது மீண்டும் இணைப்பு உள்ளமைவிலிருந்து யாரும் விளக்க முடியாத தோல்வியை உருவாக்கும் நிலையில் அமைப்பை விட்டுச் செல்கிறது. அது உரிமை முரண்பாட்டை மறைக்கிறது, அதுவே நீங்கள் தீர்க்க முயன்ற விஷயம்.

இரண்டு கூறுகள் உண்மையிலேயே ஒன்றாக வாழ வேண்டிய இடத்தில், அவற்றுக்கு வெவ்வேறு வேலைகளைக் கொடுங்கள். பிணைய மேலாளர் இடைமுக நிலை உள்ளமைவை வைத்திருக்கட்டும், VPN வாடிக்கையாளர் அதே ஒருங்கிணைப்பின் வழியாக ஒவ்வொரு இணைப்பின் DNS ஐயும் டொமைன்களையும் பங்களிக்கட்டும், கோப்பை நேரடியாக எழுதும் மூன்றாவது ஸ்கிரிப்டை அகற்றுங்கள். systemd-resolved இன் ஆவணம் அது ஆதரிக்கும் முறைகளையும் ஒவ்வொன்றும் /etc/resolv.conf இல் எதைக் காட்டுகிறது என்பதையும் விவரிக்கிறது. நீங்கள் வைத்திருக்க வேண்டிய கொள்கையின் அளவுக்குப் பொருந்தும் முறையைத் தேர்ந்தெடுங்கள். split DNS முக்கியம் என்றால், ஒவ்வொரு இணைப்பின் டொமைன்களுடன் கூடிய stub ஏற்பாடு அதைப் பாதுகாக்கிறது, upstream சேவையகங்களைக் கோப்பிற்கு நகலெடுக்கும் முறை அதை அமைதியாகத் தட்டையாக்குகிறது.

மீண்டும் இணைந்த பிறகு சரிபார்க்கவும், திருத்தத்திற்குப் பிறகு அல்ல

உங்கள் மாற்றத்திற்குப் பிறகு உடனடியாகச் சரியாகத் தோன்றும் கோப்பு எதையும் நிரூபிக்காது, ஏனெனில் அடுத்த நிகழ்வு இன்னும் நடக்கவில்லை. முன்பு அதை உடைத்த வரிசையை இயக்குங்கள்: சுரங்கப்பாதையை இறக்கி மீண்டும் உயர்த்துங்கள், DHCP குத்தகையைப் புதுப்பிக்கவும் அல்லது இடைமுகத்தை மாற்றவும், பிறகு அதே மதிப்புகளை மீண்டும் படியுங்கள்.

resolvectl query build.corp.example
resolvectl query example.com
resolvectl status | head -40

பிறகு முக்கியமான வேறுபாட்டை உறுதிப்படுத்துங்கள்: உள் பெயர் உள் சேவையகம் வழியாகத் தீர்க்கப்படுகிறது, பொது பெயர் இன்னும் வேலை செய்கிறது. எல்லாவற்றையும் உள் சேவையகத்திற்கு அனுப்பும் உள்ளமைவு, யாரோ சுரங்கப்பாதை வழியாக இணையத்தை அடைய முயலும் வரை நன்றாகத் தெரிகிறது, எல்லாவற்றையும் பொது சேவையகத்திற்கு அனுப்பும் உள்ளமைவு உள் பெயர்களைக் கசிக்கிறது.

வரிசைப்படுத்தல் குறிப்புகளில் உரிமையாளர், backend மற்றும் குறியீட்டு இணைப்பு முறையைப் பதிவு செய்யுங்கள். அந்த ஒரே பத்தி எதிர்கால தொகுப்பு மேம்படுத்தலை ஒரு சம்பவத்திலிருந்து மதிப்பாய்வு உருப்படியாக மாற்றுகிறது, அடுத்த நபர் chattr கட்டளையால் அதே முரண்பாட்டை மீண்டும் கண்டுபிடிப்பதைத் தடுக்கிறது.