Synology இல் OpenVPN ஹேண்ட்ஷேக் தோல்வியா? LAN அனுப்புதலைச் சரிபார்க்கவும்

உங்கள் மடிக்கணினி TLS ஹேண்ட்ஷேக் தோல்வியடைந்ததாகத் தெரிவிக்கிறது, எனவே சான்றிதழ்களை மீண்டும் உருவாக்கும் ஆசை எழுகிறது. அதற்கு முன் சலிப்பான கேள்வியைக் கேளுங்கள்: Synology உண்மையில் எந்த Ethernet போர்ட்டில் கேட்கிறது? இரு LAN போர்ட் உள்ள NAS க்கு இரு முகவரிகள் உண்டு, DSM இன் VPN Server தொகுப்பு அதன் OpenVPN கேட்பவரை அவற்றில் ஒன்றில் பிணைக்கிறது. திசைவி 1194 ஐ மற்ற முகவரிக்கு அனுப்பும்போது எந்தப் பொட்டலமும் சேவையை அடையாது, வாடிக்கையாளரிடம் பேச்சுவார்த்தைக்கு எதுவும் இருக்காது.

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

கேட்பவர் பிணைந்துள்ள முகவரியைக் கண்டறியுங்கள்

DSM தன் போர்ட்டுகளை LAN 1, LAN 2 என அழைக்கிறது, ஒவ்வொன்றுக்கும் தனி முகவரியும் துணை வலையமைப்பும் உண்டு. VPN Server ஐத் திறந்து, OpenVPN தாவலில் குறிப்பிட்ட இடைமுகத்தைப் படித்து, பின்னர் Control Panel ஐத் திறந்து DSM அதே இடைமுகத்தில் வைத்துள்ள IPv4 முகவரியைக் குறித்துக்கொள்ளுங்கள். அனுப்புதல் குறிப்பிட வேண்டியது இந்த இரு மதிப்புகளையே, NAS இன் புரவலன் பெயரையல்ல.

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

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

sudo netstat -anp | grep 1194

புதியதைச் சேர்ப்பதற்குப் பதிலாக இருக்கும் அனுப்புதலைத் திருத்துங்கள்

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

external 1194/udp  ->  192.0.2.20:1194/udp

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

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

பொட்டலங்கள் எப்படியாவது வந்து சேர்கின்றனவா என்பதை நிரூபியுங்கள்

முதலில் NAS இல் பிடிப்பைத் தொடங்கி, பின்னர் வாடிக்கையாளரிலிருந்து இணைந்து, வெளியீட்டில் மூல முகவரியைப் படியுங்கள். தோல்விக்குப் பின் தொடங்கிய பிடிப்பு எதையும் காட்டாது, எதையும் நிரூபிக்காது.

sudo tcpdump -i any -n udp port 1194

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

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

பொட்டலங்கள் வந்ததும் அனுப்புதலைக் குறை சொல்வதை நிறுத்துங்கள்

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

போக்குவரத்து என்பது வெளிப்படையாகச் சரிபார்க்க வேண்டிய மற்றொரு முரண்பாடு, ஏனெனில் விவரக்குறிப்பும் தொகுப்பும் வெவ்வேறு இடங்களில் திருத்தப்படுகின்றன. தொகுப்பை மாற்றாமல் விவரக்குறிப்பை UDP இலிருந்து TCP ஆக மாற்றினால் வாடிக்கையாளர் இல்லாத கேட்பவருக்காகக் காத்திருக்கும், மற்ற எல்லாவற்றுக்கும் வாடிக்கையாளர் கூறும் அதே பொதுவான ஹேண்ட்ஷேக் உரையையே கூறும். கோப்பில் proto வரியைப் படியுங்கள், பின்னர் சேவையகப் பக்கத்தில் தேர்ந்தெடுக்கப்பட்ட நெறிமுறையைப் பாருங்கள், அதன் பின்னரே அவை பொருந்துகின்றன என்று முடிவு செய்யுங்கள். DSM ஃபயர்வால் விதிகளைப் படிப்பது மூன்றாவது சரிபார்ப்பு: உள்ளூர் துணை வலையமைப்பிலிருந்து போர்ட்டைத் திறந்து இணையத்திலிருந்து திறக்காத விதியைச் சோதனைக்குப் பின் விட்டுவிடுவது எளிது, அது சமையலறையிலிருந்து வேலை செய்து எல்லா இடங்களிலும் தோல்வியடையும் இணைப்பை உருவாக்குகிறது.

தூர வாடிக்கையாளர் உண்மையில் செல்லும் பாதையைச் சோதியுங்கள்

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

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