Android-இல் தரமற்ற UDP போர்ட்டில் IKEv2 ஏன் தோல்வியடைகிறது
இயல்பான IKEv2 படிவம் முகவரியை எடுக்கும், போர்ட்டை அல்ல. கிளையண்ட் அதை ஆதரிக்கிறதா என உறுதிசெய்து, சேவையகத்தின் இரு போர்ட்களையும் அமைத்து, பின்னர் பிரேமிங் மற்றும் பதிவுகளைப் பாருங்கள்.
நுழைவாயில் UDP 4443 இல் IKEv2-க்கு ஏதோ காரணத்தால் பதிலளிக்கிறது, சுயவிவரத்தில் Server எனும் புலம் உள்ளது, நீங்கள் ஹோஸ்ட் பெயரையும் போர்ட்டையும் தட்டச்சு செய்கிறீர்கள், தொலைபேசி சேவையகத்தை அடைய முடியவில்லை அல்லது முகவரியைத் தீர்க்க முடியவில்லை எனத் தெரிவிக்கிறது. எதுவும் தடுக்கப்படவில்லை. Android-இன் இயல்பான படிவம் ஹோஸ்ட்டை எதிர்பார்க்கிறது, Windows-இலும் அதுவே உண்மை. தனிப்பயன் போர்ட் சேவையக அமைப்பாகும் முன் கிளையண்டின் திறனாகும், சில கிளையண்டுகள் மட்டுமே அதை வெளிப்படுத்த அனுமதிக்கின்றன. மூன்று பகுதிகளையும் வரிசையாகப் பாருங்கள்: கிளையண்ட் என்ன சொல்ல முடியும், சேவையகம் எதைக் கேட்கிறது, இரு முனைகளும் பாக்கெட்டுகளை ஒரே முறையில் பிரேம் செய்கின்றனவா.
தொலைபேசி உண்மையில் அனுப்பியது
பெயருக்காக உருவாக்கப்பட்ட புலத்தில் உள்ள host:port சரம் பெயராகத் தீர்க்கப்படுகிறது. தீர்வி vpn.example.net:4443-க்கு எதையும் திருப்பித் தரவில்லை, நீங்கள் காணும் பிழை போர்ட்டில் நேரம் முடிவது அல்ல, பெயர் தீர்வு அல்லது அணுகமுடியாமையின் தோல்வி. அந்த வேறுபாடு முக்கியம், ஏனெனில் குறுகிய பெயர் அல்லது வேறு பிணையத்துடன் மீண்டும் முயல்வது படிவம் பகுப்பாய்வு செய்ய முடியாத சரத்தை ஒருபோதும் சரிசெய்யாது.
Android-இல் உள்ள இயல்பான IKEv2 சுயவிவரம், Windows-இன் உள்ளமைந்த VPN கிளையண்டைப் போல, நிலையான IKE போர்ட்களில் பிணைக்கப்பட்டுள்ளது. எதுவும் போர்ட் புலத்தைக் காட்டவில்லை, சுயவிவரத் திருத்தம் ஒன்றையும் சேர்க்காது. இயக்குபவரின் கேட்பவர் உண்மையில் 4443 இல் இருந்தால், உள்ளமைந்த கிளையண்ட் தவறாக அமைக்கப்பட்டதல்ல, தவறான கருவி.
போர்ட்டைக் காட்டும் கிளையண்டைப் பயன்படுத்துங்கள்
strongSwan-இன் Android கிளையண்ட் மேம்பட்ட சுயவிவர அமைப்புகளில் கட்டமைக்கக்கூடிய சேவையக போர்ட்டைப் பதிவு செய்கிறது, அதனால்தான் இந்த வடிவமைப்புக்கு வேலை செய்யும் கிட்டத்தட்ட ஒவ்வொரு செய்முறையிலும் அது தோன்றுகிறது. அந்த ஆதரவு அந்தக் கிளையண்டுக்கே சொந்தம்: மற்றொரு IKEv2 பயன்பாடு, அல்லது அதே பயன்பாட்டின் விற்பனையாளர் கிளை, அடிப்படை strongSwan டீமன் ஆதரித்தாலும் அதே புலத்தைக் காட்டாமல் இருக்கலாம்.
இயக்குபவரிடம் முழுத் தொகுப்பையும் ஒரே நேரத்தில் கேளுங்கள்: நுழைவாயில் பெயர், UDP போர்ட், அங்கீகார முறை, மற்றும் கிளையண்ட் எதிர்பார்க்க வேண்டிய சேவையக அடையாளம். தனிப்பயன் போர்ட் சான்றிதழ் சரிபார்ப்பை அணைக்க அல்லது நெறிமுறைகளை மாற்றக் காரணமல்ல. நிறுவப்பட்ட கிளையண்ட் போர்ட்டை எதிர்பார்க்கும் இடத்தில் அதை உள்ளிடுங்கள், அந்தக் கிளையண்டில் அத்தகைய புலம் இல்லாவிட்டால், பதில் ஊகிக்கப்பட்ட தீர்வல்ல, மற்றொரு அனுமதிக்கப்பட்ட கிளையண்ட்.
சேவையகத்திற்கு இரண்டு போர்ட்கள் உள்ளன, இரண்டும் பொருந்த வேண்டும்
IKE UDP 500 இல் தொடங்குகிறது, NAT கடந்து செல்லுதல் பொதுவாக IKE மற்றும் உறைந்த ESP-ஐ UDP 4500-க்கு நகர்த்துகிறது. இவை strongSwan-இல் தனித்தனி அமைப்புகள், எனவே ஒரு தனிப்பயன் போர்ட்டுக்கு நகர்த்தப்பட்ட சேவையகம் இரண்டையும் ஒரே மதிப்புக்கு மாற்ற வேண்டும்:
plugins {
socket-default {
port = 4443
port_nat_t = 4443
}
}
ஒரே போர்ட் இரு பங்குகளுக்கும் இருக்கும்போது, டீமன் அதே சாக்கெட்டில் IKE-ஐ ESP-in-UDP-இலிருந்து வேறுபடுத்த வேண்டும், அதை IKE செய்திக்கு முன் வரும் நான்கு பைட் ESP அல்லாத குறியால் செய்கிறது. அதனால் கிளையண்ட் தனிப்பயன் போர்ட்டில் பேச்சுவார்த்தை நடத்தி பின்னர் அமைதியாக 4500-இல் தொடர முடியாது, அதனால்தான் “போர்ட்டை மாற்றுங்கள் அவ்வளவே” எனும் சொற்றொடர் பிரேமிங் தேவையை மறைக்கிறது.
அனுப்புதல் கேட்பவர் அல்ல
4443-ஐ சாதாரண IKE கேட்பவருக்கு அனுப்புவது கிட்டத்தட்ட வெற்றிகரமாகத் தோன்றும் தோல்வி முறை. முதல் பரிமாற்றம் வருகிறது, சேவையகம் பதிலளிக்கிறது, பின்னர் இணைப்பு நிற்கிறது அல்லது எதற்கும் விசைகளை மீண்டும் உருவாக்குகிறது, ஏனெனில் பதில் வேறு போர்ட்டிலிருந்து வெளியேறுகிறது, பின்னர் உறைந்த போக்குவரத்து இரு முனைகளும் உருவாக்கிய நிலையுடன் ஒருபோதும் பொருந்தாது. கேட்பவரை நகர்த்தாமல் இலக்கு போர்ட்டை மீண்டும் எழுதும் விதி சரியாக இந்த பாதி-திறந்த முடிவைத் தருகிறது.
பாதை UDP-ஐயும் முனையிலிருந்து முனை வரை அனுமதிக்க வேண்டும். TCP 443 ஒரு ஹோட்டல் அல்லது இயக்குபவர் பிணையத்தின் வழியாகச் செல்வது UDP போர்ட்டில் IKEv2 பற்றி எதையும் சொல்லாது, எண் ஒன்றாக இருந்தாலும். TCP 443 மட்டும் அனுமதிக்கப்படும் இடத்தில், தனிப்பயன் UDP போர்ட் IKEv2-ஐ HTTPS ஆக்காது, சரியான பதில் மற்றொரு போர்ட் பரிசோதனை அல்ல, வேறு அணுகல் பாதையாக இருக்கலாம்.
சோதிக்கும்போது மூன்று நிலைகளைப் பிரிக்கவும்
கிளையண்ட் ஒருமுறை முயலும்போது சேவையகத்தில் பிடிக்கவும். ஒருபோதும் வராத கோரிக்கை முனை அல்லது தீச்சுவர் கேள்வி; பதிலின்றி வரும் கோரிக்கை கேட்பவர் அல்லது கொள்கை கேள்வி; பதிலைத் தொடர்ந்து மௌனம் வந்தால் அது பிரேமிங் அல்லது அடையாளக் கேள்வி.
tcpdump -ni eth0 -vv udp port 4443
பின்னர் கிளையண்டின் சுழலும் குறியீட்டை அல்ல, அதன் செய்தியைப் படியுங்கள். முன்மொழிவுப் பிழை என்பது அல்காரிதங்கள் பொருந்தவில்லை என்பதாகும், அங்கீகாரத் தோல்வி என்பது அடையாளங்கள் அல்லது சான்றிதழ்கள் பொருந்தவில்லை என்பதாகும், பதிலின்றி மீண்டும் மீண்டும் அனுப்புதல் என்பது அந்தப் போர்ட்டில் எதுவும் பதிலளிக்கவில்லை என்பதாகும். ஒரு நேரத்தில் ஒரு நிலையைச் சோதித்து முயற்சிகளுக்கு இடையில் ஒரு புலத்தை மாற்றுங்கள்; NAT கடந்து செல்லுதல் பற்றிய strongSwan ஆவணங்கள் பிடிப்பு உங்களுக்குக் காட்டும் குறி மற்றும் போர்ட் நடத்தையை விவரிக்கின்றன.