iPhone Always On VPN: दो टनल एक वर्चुअल IP साझा कर सकते हैं

प्रबंधित Always On प्रोफ़ाइल वाले निगरानी में रखे iPhone पर फ़ोन हर सक्रिय IP इंटरफ़ेस के लिए एक टनल रखता है, इसलिए सेलुलर और Wi-Fi दोनों को अपनी-अपनी टनल मिलती है। फिर सर्वर एक डिवाइस के लिए दो IKE सुरक्षा संबद्धताएँ सूचीबद्ध करता है, अक्सर एक वर्चुअल पता साझा करते हुए, और पहली प्रवृत्ति इसे rekey लूप कहने और टाइमर बदलने की होती है। यह प्रवृत्ति आमतौर पर ग़लत होती है। नीचे दिए चरणों को उसी क्रम में करें जिस क्रम में साक्ष्य सर्वर पर दिखते हैं, और जब तक सर्वर न बताए कि आपका कौन-सा मामला है, फ़ोन की सेटिंग्स को छोड़ दें।

सर्वर के पास पहले से मौजूद दो पंक्तियों से शुरू करें

संबद्धताओं को swanctl --list-sas से सूचीबद्ध करें और दोनों प्रविष्टियों में चार फ़ील्ड पढ़ें: दूरस्थ पता, प्रमाणित पहचान, आवंटित वर्चुअल IP और निर्माण समय। एक पहचान और एक वर्चुअल IP के साथ दो अलग बाहरी पते वही आकार हैं जिसने यह प्रश्न शुरू किया, और किसी भी बदलाव से पहले इसे लिख लेना उचित है। फिर प्रत्येक से जुड़ी चाइल्ड संबद्धताएँ जाँचें, क्योंकि ट्रैफ़िक चयनकर्ता तय करते हैं कि कोई गंतव्य खोज कभी दोनों टनल में अंतर कर सकती है या नहीं। कुछ सेकंड में दिखकर गायब हो जाने वाला जोड़ा घंटों तक जीवित रहने वाले जोड़े से अलग जानवर है।

निष्कर्ष निकालने से पहले सूची को निर्माण समय के अनुसार क्रमबद्ध करें। आउटपुट में निकटता का कोई अर्थ नहीं है, और सारणीबद्ध सूची ठीक उसी ग़लती को आमंत्रित करती है।

तय करें कि आप कौन-सा अतिव्यापन देख रहे हैं

IKEv2 rekey और make-before-break पुनःप्रमाणन जानबूझकर एक छोटा अतिव्यापन बनाते हैं, पुरानी संबद्धता हटाने से पहले नई को स्थापित करके। समय-चिह्न मामला तय करते हैं, क्योंकि नई के दिखने के एक-दो सेकंड बाद गायब होने वाली पुरानी SA नवीनीकरण है जो अपना काम कर रही है। स्वतंत्र इंटरफ़ेस टनल कभी ऐसी नहीं दिखतीं, क्योंकि हर एक तब तक बनी रहती है जब तक उसका इंटरफ़ेस चालू है, और एक को हटाना दूसरी को बनाने से नहीं आता।

Apple का प्रबंधित Always On व्यवहार प्रति इंटरफ़ेस है, इसलिए निगरानी में रखा डिवाइस हाथ से सेट किए गए प्रोफ़ाइल से वैध रूप से अधिक व्यस्त दिख सकता है। किसी प्रदाता ऐप का ऑटो-कनेक्ट टॉगल वही बात नहीं दर्शाता, और सामान्य on-demand नियम भी नहीं। Apple का परिनियोजन अवलोकन प्रति इंटरफ़ेस मॉडल का वर्णन करता है; लूप मानने से पहले अपनी दोनों पंक्तियों की उससे तुलना करें। दोनों आकार सर्वर के एक ही पूल से लेते हैं, इसलिए अतिव्यापन ही आपका एकमात्र प्रारंभिक संकेत है।

देखें कि एक वर्चुअल पता दो टनल के लिए उत्तर क्यों तोड़ता है

फ़ोन को उत्तर आंतरिक पते पर भेजा जाता है, और कर्नेल गंतव्य और नीति से आउटबाउंड टनल चुनता है, उस इंटरफ़ेस से नहीं जो फ़ोन ने इस्तेमाल किया। समान वर्चुअल IP रखने वाली और मेल खाती नीतियों वाली दो समवर्ती संबद्धताएँ राउटिंग निर्णय को यह कहने का कोई तरीका नहीं छोड़तीं कि उत्तर किस सत्र का है। कुछ उत्तर ग़लत टनल ले लेते हैं, और फ़ोन एक दिशा में चलने वाला या Wi-Fi आने पर मर जाने वाला कनेक्शन दिखाता है। दो कमांड आउटपुट स्थिति साबित करते हैं: swanctl --list-sas दोनों SA पर एक ही वर्चुअल IP दिखाता है, और ip xfrm policy दो समान चयनकर्ता दिखाता है।

यही आउटपुट जोड़ी आप परिवर्तन रिकॉर्ड में चिपकाते हैं। अकेले कोई भी विश्वसनीय नहीं है, क्योंकि हर एक अलग से प्रशंसनीय लग सकता है।

यह सर्वर पक्ष का पता और नीति है, फ़ोन का दुर्व्यवहार नहीं, और कोई क्लाइंट सेटिंग दो समान आंतरिक पतों को अलग नहीं करती। पूल ने वही मान दो बार दिया और नीति इंस्टॉलर ने उसे स्वीकार कर लिया। क्लाइंट को दोष देने से पहले परिणाम सर्वर की ओर से पढ़ें।

पूल या समवर्ती मॉडल बदलें, rekey टाइमर नहीं

swanctl कॉन्फ़िगरेशन में, विशिष्टता कनेक्शन पर एक स्पष्ट नीति है: unique = replace नया स्थापित होने पर पुराने कनेक्शन को हटाता है, और unique = keep नए आगंतुक को अस्वीकार करता है। दोनों मान कनेक्शन स्थापित होते समय काम करते हैं, उसके अंदर की चाइल्ड SA पर नहीं।

connections {
  ios-alwayson {
    unique = replace
  }
}

प्रति इंटरफ़ेस क्लाइंट के लिए कोई भी मान तटस्थ नहीं है। keep दूसरी टनल को अस्वीकार करके साफ़ स्थिति स्क्रीन बहाल करता है और प्रबंधित डिज़ाइन तोड़ता है, जबकि replace पुरानी टनल को गिरा देता है और दूसरी दिशा में वही समझौता है। यदि वास्तव में दोनों टनल आवश्यक हैं, तो पूल बैकएंड को एक पहचान के लिए अलग लीज़ जारी करनी होंगी, और उसकी लीज़ कुंजी को अनुरोधों में अंतर करना होगा। स्थिर पहचान-से-पता तालिका ख़ुशी से वही पता दो बार लौटाएगी और मूल समस्या को अधिक कॉन्फ़िगरेशन के साथ दोहराएगी। दूसरा स्थिर मैपिंग जोड़ने से पहले जाँचें कि बैकएंड लीज़ को कैसे कुंजीबद्ध करता है।

उन बदलावों का परीक्षण करें जो आप वास्तव में तैनात करते हैं

सक्रिय सत्र के साथ Wi-Fi की सीमा से बाहर जाएँ, फिर वापस आएँ, और जाँचें कि उत्तर दोनों दिशाओं में आते हैं। इसे दो बार करें, क्योंकि दूसरा संक्रमण वही जगह है जहाँ पुरानी नीति आमतौर पर दिखती है। उस सेवा से परीक्षण करें जो आपके खोले कनेक्शन पर उत्तर देती है, और बाहर जाना तब दोहराएँ जब टनल ट्रैफ़िक ले जा रही हो, न कि खाली बैठी हो। जो फ़ोन भेज सकता है पर प्राप्त नहीं कर सकता, वह handshake लॉग में स्वस्थ और ब्राउज़र में टूटा दिखता है।

एक पंक्ति तक सिमटी स्थिति स्क्रीन काम कर रहे डिज़ाइन का प्रमाण नहीं है, केवल यह प्रमाण है कि एक टनल चली गई। संक्रमण पास होने से पहले दोनों दिशाओं को काम करना होगा। आपने जो देखा उसे अतिव्यापन जाँच के दोनों आउटपुट के साथ लिखें, ताकि अगला इंजीनियर दोहराने के बजाय तुलना कर सके।