OpenVPN வீட்டில் வேலை செய்கிறது ஆனால் ஒரு நெட்வொர்க்கில் இல்லை: UDP அல்லது TCP?

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

எந்த நிலை தோல்வியடைந்தது என்பது எந்த ஒப்பீடு முக்கியம் என்பதைச் சொல்கிறது

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

பின்னர் அல்ல, மீண்டும் முயற்சிக்கும்போது பிடியுங்கள். கிளையண்டில் tcpdump -ni any udp port 1194 எந்தப் பதிலும் திரும்பி வருமா என்பதைக் காட்டுகிறது. நீங்கள் கட்டுப்படுத்தும் சேவையகத்தின் WAN இடைமுகத்தில் அதை மீண்டும் செய்யுங்கள், இது அந்தப் பாக்கெட்டுகள் தொலை முனைக்கு வருமா என்பதை வெளிப்படுத்தும்.

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

UDP வடிகட்டுதல் மற்றும் மூடிய துறை

பல அணுகல் நெட்வொர்க்குகள் தொடர்ச்சியான UDP-ஐ சந்தேகத்திற்குரியதாகக் கருதுகின்றன, சில ISP-களும் ஒப்புக்கொள்கின்றன. மூடிய துறை கிளையண்ட் பக்கத்திலிருந்து அதே மௌனத்தை உருவாக்குகிறது. வேறுபாடு தேர்ந்தெடுப்புத்தன்மை: வடிகட்டி எந்த இலக்குகள் அல்லது துறைகளை விட்டுவிடுகிறது என்பதில் தேர்ந்தெடுக்கிறது, மூடிய துறை அந்தத் துறையை நோக்கிய அனைத்தையும் நிராகரிக்கிறது.

443 துறையில் TCP சுயவிவரம் வழக்கமான தீர்வு, ஏனெனில் அது சாதாரண HTTPS ஓட்டத்தைப் போலத் தெரிகிறது மற்றும் பெரும்பாலான captive போர்ட்டல்கள் மற்றும் வெளியேறும் வடிகட்டிகளைக் கடக்கிறது. இரண்டு நிபந்தனைகள் நிறைவேற வேண்டும். சேவையகம் proto tcp-server உடன் கேட்க வேண்டும், கிளையண்ட் proto tcp-client உடன் பொருந்த வேண்டும், மேலும் இயக்குபவர் அந்த மாற்று முனையத்தை வெளியிட வேண்டும். வேலை செய்யும் UDP சுயவிவரத்தை TCP 443 என மீண்டும் எழுதுவது மறுபக்கம் யாரும் கேட்காதபோது எதையும் அடையாது.

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

பழைய நெறிமுறைகள் இந்த அச்சில் மோசமாக ஒப்பிடுகின்றன. PPTP-க்கு TCP 1723 மற்றும் GRE தேவை, GRE என்பது துறை அல்ல, IP நெறிமுறை 47, எனவே சாதாரண துறை அனுப்புதல் அதை வெளிப்படுத்த முடியாது.

சுவிட்சே பாக்கெட்டுகளை விடும்போது

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

சுவிட்ச் விடுவதையும் வழங்குநர் தடுப்பையும் பிரிப்பது எதிர் ஆதாரம். ISP-யிடம் டிக்கெட் திறப்பதற்கு முன் இடைமுக எண்ணிகள் மற்றும் வெள்ளப் பாதுகாப்புப் பதிவைப் படியுங்கள். DoS அல்லது வெள்ளப் பாதுகாப்பு கொண்ட நுகர்வோர் ரவுட்டர்கள் அதே வடிவத்தில் தோல்வியடைகின்றன, குறுகிய UDP செயலற்ற நேர வரம்பு கொண்ட எந்த இடைநிலைப் பெட்டியும் அவ்வாறே. ஒருபோதும் முடிவடையாத கைக்குலுக்கல் விடுவதைக் குறிக்கிறது, சில நிமிட மௌனத்திற்குப் பின் இறக்கும் சுரங்கப்பாதை நேர வரம்பைக் குறிக்கிறது.

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

DNS தோல்வி போலத் தெரியும் முகவரி மேற்பொருந்துதல்

10.0.0.0/8-க்குள் எண்ணிடப்பட்ட அணுகல் நெட்வொர்க் சுரங்கப்பாதைக் குளத்துடன் மேற்பொருந்தலாம், தீர்வான் பொதுவாக அந்தக் குளத்திற்குள்ளேயே வாழ்கிறது. மடிக்கணினி Wi-Fi-யில் 10.184.178.50 போன்ற முகவரியை /8 முகமூடியுடன் பெறும்போது, ஒவ்வொரு 10.x இலக்கும் வரையறையின்படி உள்ளூர். 10.4.0.1 க்கான பாக்கெட்டுகள் பின்னர் LAN-க்குச் செல்கின்றன, சுரங்கப்பாதை மேலேயே இருக்கிறது, பெயர் தீர்வு தோல்வியடைகிறது.

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

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

TCP மாற்று வழிக்கும் பாதை திருத்தத்திற்கும் இடையே தேர்வு

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

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