Android पर गैर-मानक UDP पोर्ट पर 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 का दस्तावेज़ वह मार्कर और पोर्ट व्यवहार बताता है जो कैप्चर आपको दिखा रहा है।