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 को कागजातले क्याप्चरले तपाईंलाई देखाइरहेको मार्कर र पोर्ट व्यवहार वर्णन गर्छ।