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 को दायराबाट बाहिर जानुहोस्, त्यसपछि फर्केर आउनुहोस्, र जवाफ दुवै दिशामा आउँछन् भनी जाँच्नुहोस्। त्यो दुई पटक गर्नुहोस्, किनकि दोस्रो संक्रमण नै पुरानो नीति प्रायः देखिने ठाउँ हो। तपाईंले खोलेको जडानमा जवाफ दिने सेवासँग परीक्षण गर्नुहोस्, र टनेल निष्क्रिय बस्नुको सट्टा ट्राफिक बोक्दै गर्दा बाहिर जाने क्रम दोहोर्याउनुहोस्। पठाउन सक्ने तर स्वीकार्न नसक्ने फोन ह्यान्डसेक लगमा स्वस्थ र ब्राउजरमा बिग्रिएको देखिन्छ।

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