அலுவலகத் தீர்விக்கு ping "OpenVPN" இணைந்த பிறகும் பதில் வருகிறது, இருப்பினும் ஒவ்வொரு பெயர்த் தேடலும் தோல்வியடைகிறது. முகவரி அடையக்கூடியது, போர்ட் அல்ல, Windows அடாப்டர் வாரியாக DNS வடிகட்ட முடியும் எனத் தெரிந்தால் இந்தக் கலவை புரியும். சுயவிவரத்தில் block-outside-dns இருந்தால் அந்த வடிகட்டியே முதல் சந்தேகநபர், மேலும் வழித்தட அட்டவணை பார்க்கத் தவறான இடம். கீழேயுள்ள இரண்டு சோதனைகள் அடுக்குகளை சில வினாடிகளில் பிரிக்கின்றன.

அடையக்கூடிய முகவரி, இறந்த போர்ட்

வெற்றிகரமான ping ஹோஸ்ட் இயங்குவதையும் ஒரு வழி இருப்பதையும் நிரூபிக்கிறது. போர்ட் 53 ஐ அடையும் அனுமதியைப் பற்றி அது எதுவும் சொல்லாது, ஏனெனில் சம்பந்தப்பட்ட வடிகட்டி வேறு அடுக்கில் வேலை செய்கிறது, அடாப்டரைச் சார்ந்துள்ளது. அதனால்தான் அதே இயந்திரம் ICMP க்கு பதிலளித்து, அதே முகவரிக்கு அனுப்பப்படும் ஒவ்வொரு வினவலையும் நிராகரிக்க முடியும். எந்தவொரு கட்டமைப்பையும் மாற்றும் முன் இரண்டு சோதனைகளையும் ஒரே அமர்வில் இயக்கவும்.

ping <resolver-ip>
nslookup <name> <resolver-ip>

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

இந்த விருப்பம் வடிகட்டும் தளத்தின் விதி

OpenVPN குறிப்பு block-outside-dns ஐ Windows Filtering Platform இன் கட்டுப்பாடு என விவரிக்கிறது, அது சுரங்கத்திற்கு வெளியே உள்ள அடாப்டர்களில் பயன்பாடுகள் DNS ஐ அடைவதைத் தடுக்கிறது. இது TCP மற்றும் UDP போர்ட் 53 ஐ உள்ளடக்குகிறது. வடிகட்டி சாதாரண தீச்சுவர் விதிப் பட்டியலில் இல்லாமல் WFP இல் வாழ்வதால், வேறு இடத்தில் அனுமதி விதி சேர்ப்பது விளைவை அவசியம் மாற்றாது. அதனால்தான் DNS ஐ அனுமதிக்கும் பொதுவான ஆலோசனை தோல்வியடைந்து கொண்டே இருக்கிறது.

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

மேலும் விதிகள் சேர்ப்பதற்குப் பதிலாக அந்தக் கட்டுப்பாட்டைக் கொண்ட வாடிக்கையாளர் கூறைத் தேடுங்கள். உரிமையாளரே அதை உண்மையில் நீக்கக்கூடியது.

வடிகட்டி தீர்வி அல்ல

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

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

  1. பயன்பாட்டில் உள்ள தீர்வி: Resolve-DnsName -Server <resolver-ip> <name> ஐ ipconfig /all பட்டியலிடும் DNS சேவையகங்களுடன் ஒப்பிடுங்கள்.
  2. VPN DNS பயன்படுத்தப்பட்டது: அதே ipconfig /all வெளியீட்டில் சுரங்க அடாப்டரின் DNS பதிவுகளைப் பார்க்கவும்.
  3. பயன்படுத்திய இடைமுகம்: Find-NetRoute -RemoteIPAddress <resolver-ip> அந்த இலக்கிற்கான வெளிச்செல்லும் இடைமுகத்தைக் குறிப்பிடுகிறது.

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

இந்த விருப்பம் எதை உள்ளடக்கவில்லை

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

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

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

இணைப்புத் துண்டிப்புக்கு முன்னும் பின்னும் நிலையைச் சரிபார்க்கவும்

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

ipconfig /displaydns
nslookup <name> <resolver-ip>

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

இந்தச் சரிபார்ப்புகளுக்குப் பிறகே தீர்வியை மாற்றுவதோ தீச்சுவர் கொள்கையை மீண்டும் கட்டுவதோ அர்த்தமுள்ளது. இரண்டும் ஆதாரங்கள் ஆதரிப்பதை விடப் பெரிய மாற்றங்கள்.

தொடர்புடைய கட்டுரைகள்