OpenVPN ஒரு DNS சேவையகத்தை அனுப்பியது, ஆனால் Linux அதைப் புறக்கணிக்கிறது

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

சரிபார்ப்பு ஒன்று: இணைப்பு எவ்வாறு தொடங்குகிறது

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

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

தொடர்வதற்கு முன் உரிமையாளரை எழுதி வையுங்கள். அடுத்தடுத்த ஒவ்வொரு சரிபார்ப்பும் அதைச் சார்ந்தது.

சரிபார்ப்பு இரண்டு: தீர்வியின் இணைப்பு உண்மையில் எதை வைத்திருக்கிறது

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

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

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

சரிபார்ப்பு மூன்று: பெயரிடை அந்த இணைப்பைத் தேர்ந்தெடுக்கிறதா

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

கள ஒதுக்கீட்டைச் சரிபார்க்கவும், சேவையக முகவரியை மட்டுமல்ல. ~corp.example என எழுதப்பட்ட களம் ஒரு வழிசெலுத்தல் களம், மேலும் டில்டே குறி பெயர் எவ்வாறு பொருந்துகிறது என்பதை மாற்றுகிறது.

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

சரிபார்ப்பு நான்கு: ஒரு உரிமையாளர், இரண்டு அல்ல

NetworkManager ஏற்கனவே VPN மற்றும் தீர்வியின் நிலையை நிர்வகித்தால், தொடர்பில்லாத கொக்கி ஸ்கிரிப்டைச் சேர்ப்பது போட்டியிடும் எழுத்தாளர்களை உருவாக்கும். தொகுப்பு systemd-resolved-க்கு வழங்கும் கொக்கி ஆதரிக்கப்பட்ட ஒருங்கிணைப்பு, அது ஒரு குறிப்பிட்ட வாழ்க்கைச் சுழற்சியை எதிர்பார்க்கிறது: script-security 2, up பாதை, up-restart, down பாதை மற்றும் down-pre. அந்த விருப்பங்கள் பதிவு மற்றும் அகற்றுதல் முதல் இணைப்பில் மட்டுமல்ல, சரியான தருணங்களில் நடக்க வைக்கின்றன.

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

அதன் வெளியீட்டு இலக்கை மாற்ற ஒரு விநியோகத்தின் தீர்வி ஸ்கிரிப்டைத் திருத்துவது ஒரு ஹோஸ்ட்டின் தீர்வைப் பதிவு செய்கிறது. அது பொதுவான பழுதுபார்ப்பு அல்ல.

சரிபார்ப்பு ஐந்து: மீண்டும் இணைந்த பிறகு அதே முடிவு

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

மறுஇணைப்பில் ஐந்து சரிபார்ப்புகளும் கடந்தால் மட்டுமே அனுப்பப்பட்ட அமைப்புகள் பயன்பாட்டில் உள்ளன என்று சொல்ல முடியும். அதற்கு முந்தைய அனைத்தும் ஒரு அதிர்ஷ்டமான தருணத்தின் புகைப்படம்.