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 दस्तऐवज कॅप्चर तुम्हाला दाखवत असलेला मार्कर आणि पोर्ट वर्तनाचे वर्णन करते।

संबंधित लेख