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 च्या श्रेणीबाहेर जा, नंतर परत या, आणि उत्तरे दोन्ही दिशांनी येतात याची खात्री करा। ते दोनदा करा, कारण दुसरे संक्रमण हेच जुने धोरण सहसा दिसण्याचे ठिकाण आहे। तुम्ही उघडलेल्या कनेक्शनवर उत्तर देणाऱ्या सेवेसह चाचणी करा, आणि बोगदा निष्क्रिय बसण्याऐवजी रहदारी वाहत असताना बाहेर जाणे पुन्हा करा। पाठवू शकणारा पण स्वीकारू न शकणारा फोन हँडशेक लॉगमध्ये निरोगी आणि ब्राउझरमध्ये तुटलेला दिसतो।

एका ओळीवर आलेली स्थिती स्क्रीन कार्यरत रचनेचा पुरावा नाही, फक्त एक बोगदा गेल्याचा पुरावा आहे। संक्रमण पास होण्यापूर्वी दोन्ही दिशांनी कार्य करणे आवश्यक आहे। तुम्ही जे पाहिले ते आच्छादन तपासणीच्या दोन आउटपुटसह लिहून ठेवा, जेणेकरून पुढील अभियंता पुनरावृत्तीऐवजी तुलना करू शकेल।