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

பிழைக் குறியீட்டை தீர்ப்பாக அல்ல, நிலையாகப் படியுங்கள்

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

What the client saysStage that failedFirst thing to run
868, name did not resolveDNS, before any packet leaves for the serverResolve-DnsName vpn.example.net
721 or 806, remote computer did not respondOuter protocol filtered, typically GRE or UDPA capture on the local interface
809, server not respondingA device in the path is dropping the outer flowThe same capture, from a second network
789, security layer errorThe security exchange started and was rejectedCertificate and proposal settings on both ends

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

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

சுரங்கப்பாதையைக் குறை சொல்வதற்கு முன் பெயரைச் சரிபாருங்கள்

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

Resolve-DnsName vpn.example.net -Type A
nslookup vpn.example.net 1.1.1.1
ipconfig /all | findstr /i "DNS Servers"

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

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

எந்த வெளிப்புறப் பொதி மறைகிறது என்பதைக் கண்டறியுங்கள்

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

pktmon filter remove
pktmon filter add -p 500 -t UDP
pktmon start --capture --pkt-size 128
pktmon stop
pktmon etl2txt PktMon.etl

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

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

ஒரு போக்குவரத்தை மாற்றி மீண்டும் சோதியுங்கள்

வெளிப்புற ஓட்டம் வீசப்படுகிறது என்று தெரிந்ததும், நடைமுறைக் கேள்வி வலைப்பின்னல் எந்த ஓட்டத்தை அனுமதிக்கிறது என்பதே. பெரும்பாலான கட்டுப்படுத்தப்பட்ட வலைப்பின்னல்கள் வெளிச்செல்லும் TCP 443-ஐ அனுமதிக்கின்றன, இல்லையேல் அவற்றால் இயங்க முடியாது, எனவே கேட்பானை அங்கு நகர்த்துவதே வழக்கமான பதில். OpenVPN-ல் இது சேவையகம் மாற்றப்படும் வரை வாடிக்கையாளர் பக்கச் சுவிட்சு:

openvpn --config corp.ovpn --proto tcp-client --remote vpn.example.net 443 --verb 4

IPsec வாடிக்கையாளர்களுக்கு அவர்களின் சொந்த அமைப்புப் பலகைகளில் இணையான சுவிட்சு உள்ளது, பொதுவாக TCP மேல் IPsec அல்லது NAT கடத்தல் என விவரிக்கப்படுகிறது. அதை மாற்றுவதும் ஒரு கண்டறிதல்: சுரங்கப்பாதை TCP மேல் ஏறி UDP மேல் இறந்தால், வலைப்பின்னல் UDP-ஐ வடிகட்டுகிறது என்பதை நீங்கள் நிரூபித்தீர்கள், அந்த இடத்திற்கு ஒவ்வொரு வருகையிலும் தேவைப்படும் அமைப்பையும் கண்டுபிடித்தீர்கள்.

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

இரண்டாவது வலைப்பின்னலில் அதே விவரக்குறிப்பைச் சரிபாருங்கள்

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

pktmon filter add -p 443 -t TCP
pktmon start --capture
Get-VpnConnection -Name "Corp" | Select-Object ConnectionStatus, TunnelType, ServerAddress

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

பின்னர் அடுத்த நபர் பார்க்கும் இடத்தில் கண்டுபிடிப்பை எழுதுங்கள். "இந்தத் தளத்தில் நிறுவன விவரக்குறிப்புக்கு TCP 443 தேவை; UDP 500-ஐ ஹோட்டல் வடிகட்டுகிறது" என்பது சக ஊழியர் செயல்படக்கூடிய வாக்கியம். "ஹோட்டல்களில் VPN நிலையற்றது" அப்படி இல்லை, அடுத்த மாதம் அதே ஒரு மணி நேரம் மீண்டும் வீணாகும் என்பதற்கு உத்தரவாதம் அளிக்கிறது.

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