फोनको Wi-Fi Calling नबिगारी IPsec ब्लक गर्ने

अनुरोध सधैं एउटै आकारमा आउँछ: किनारमा IPsec बन्द गर्नुहोस् किनभने यसले कसैले स्वीकृत नगरेका सुरुङहरू बोक्छ, र पहिलो उजुरी त्यो व्यक्तिबाट आउँछ जसको फोनले Wi-Fi मा फोन गर्न छोड्यो। दुवै तथ्य एकै समयमा सत्य हुन्, र कुनैले पनि नियन्त्रण छोड्ने समर्थन गर्दैन। फायरवाललाई नाम दिइएको सुविधा, सीमित स्रोत, कागजात भएका गन्तव्य र मालिक सहितको सेवा-अपवाद चाहिन्छ। पाँच चरणले त्यसलाई आउँदो वर्ष अपरिचित व्यक्तिले समीक्षा गर्न सक्ने नियममा बदल्छ।

प्रोटोकलको नाम दिनु अघि सेवाको नाम दिनुहोस्

SIP सेवाको डेस्क फोन र वाहकको Wi-Fi Calling गर्ने ह्यान्डसेटले एउटै नेटवर्क प्रोफाइल बाँड्दैन, र फायरवाल शब्दको रूपमा VoIP ले तीमध्ये कुनैलाई पनि वर्णन गर्दैन। पोर्ट र गन्तव्यको डेटा सेवा सञ्चालन गर्ने विक्रेता वा वाहकबाट आउनुपर्छ, अर्को फोन प्रणालीको सम्झनामा रहेको पोर्ट सूचीबाट होइन। यो सुविधाको रक्षा गर्ने नियम र शब्दको रक्षा गर्ने नियमबीचको भिन्नता हो।

Apple को सेवा-पोर्ट सन्दर्भ ले Wi-Fi Calling का लागि UDP 500 र 4500 सूचीबद्ध गर्छ, जो अधिकांश सामान्य IPsec ब्लकहरूले छोड्ने ठ्याक्कै त्यही जोडी हो। ती पोर्टको छेउमा परिवर्तन अभिलेखमा सुविधाको नाम लेख्नुहोस्। तपाईंले प्रयोग गरेको सन्दर्भको संस्करण वा मिति थप्नुहोस्, किनभने विक्रेताका तालिका सम्पादन हुन्छन्। आफ्नै लागि रहेको सेवाको नाम लिने नियमको समीक्षा हुन सक्छ; प्रोटोकल श्रेणीको नाम लिनेको हुँदैन।

अपवादलाई कृपा नभई करारका रूपमा लेख्नुहोस्

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

अपवादलाई बाँकी किनार नीतिकै उही चक्रमा राख्नुहोस्, ताकि वाहकले गन्तव्य सार्दा वा फ्लीटले ह्यान्डसेट मोडेल फेर्दा अर्को खराबीमा नभई समीक्षामा थाहा होस्। बिग्रिएका कल रिपोर्ट गर्नेसँग चक्र बन्द गर्नुहोस्, किनभने ब्लकले बन्द गर्न खोजेको सुरुङ फेरि नखोली सुधार पुष्टि गर्न सक्ने उनी मात्र हुन्। त्यो पुष्टि पनि मितिसहित अभिलेखमा हुनुपर्छ।

अस्थायी फोन-सुधार भनी लेबल लगाइएको स्थायी अनुमति दुई वर्षपछि टिकाउ हुँदैन। पहिचान गरिएको सेवासँग बाँधिएको अनुमतिको जानाजान नवीकरण हुने म्याद हुन्छ।

स्रोतलाई इमानदारीपूर्वक सीमित गर्नुहोस्

अपवादलाई व्यवस्थित उपकरण खण्डमा सीमित गर्नु भवनको हरेक ल्यापटपका लागि प्रोटोकल खोल्नुभन्दा धेरै बलियो हुन्छ। यदि नेटवर्कले त्यो खण्ड चिन्न सक्दैन भने नियमले उपकरण चिन्छ भन्ने संकेत दिनुभन्दा त्यो लेख्नुहोस्। सबैभन्दा सस्तो राम्रो नतिजा अर्को कारणले पहिले नै रहेको सीमा पुनः प्रयोग गर्नु हो, जसले अपवादले नयाँ नियन्त्रण आविष्कार गर्नुभन्दा एउटा उत्तराधिकारमा पाउँछ। ठेगानाअनुसार फिल्टर गर्नु उपकरण प्रमाणीकरण होइन, र परिवर्तन अभिलेखले विपरीत संकेत गर्नु हुँदैन।

स्रोत ठेगाना वा हार्डवेयर ठेगाना भौतिक ह्यान्डसेटको प्रमाण होइन। तीमध्ये कुनैको अर्थ छ कि छैन त्यो त्यस खण्डभित्रका अन्य नियन्त्रणमा पूर्ण निर्भर छ। यदि नियमको तर्क MAC ठेगानामा टिकेको छ भने नियम जारी हुनुअघि प्रयोगकर्तालाई त्यो बदल्नबाट के रोक्छ भनी जाँच्नुहोस्।

पोर्ट नियमले भन्न नसक्ने कुरा स्वीकार्नुहोस्

पोर्टले यातायातका अन्त्यबिन्दु पहिचान गर्छ, व्यापारिक मनसाय होइन। जब स्वीकृत कल सेवा र अस्वीकृत सुरुङ दुवै एउटै UDP 4500 मा जान्छन्, कुनै पोर्ट-आधारित नियमले तिनलाई छुट्याउँदैन। त्यसो गर्छु भन्ने नियम सटीक देखिन्छ तर हुँदैन, जो आफ्नै आकार स्वीकार्ने नियमभन्दा नराम्रो हो। यो संयन्त्रको सीमा हो, लेख्ने व्यक्तिको गल्ती होइन।

त्यो नियमको छेउमा भन्नुहोस्, र अपवादलाई नेटवर्कसँग भएको कार्यान्वयनसँग, जस्तै उपकरण व्यवस्थापन वा अनुमत गन्तव्य सूचीसँग जोड्नुहोस्। त्यसपछि अपवादलाई उपकरणले दिने सबैभन्दा साँघुरो रूपमा व्यक्त गर्नुहोस्, उदाहरणका लागि खण्ड र पोर्ट जोडीको नाम लिने र सामान्य निषेध तिनका पछि राख्ने nftables नियमहरू:

nft add rule inet edge forward ip saddr 10.40.0.0/24 udp dport { 500, 4500 } counter accept
nft add rule inet edge forward udp dport { 500, 4500 } counter drop

nftables ले क्रममा मूल्याङ्कन गर्छ र पहिलो मिलानमा रोकिन्छ, त्यसैले सीमित अनुमति सामान्य निषेधभन्दा माथि हुनुपर्छ। दुवै उल्टाउनुहोस् र अपवाद चुपचाप केही गर्दैन।

सुविधा र निषेध प्रमाणित गर्नुहोस्

स्वीकृत प्रमाणीकरण सामान्य Wi-Fi कलमा, अपवाद जुन उपकरण वर्गका लागि छ त्यहीँबाट चलाउनुहोस्, र बाहिर राखिएको क्लाइन्ट अझै असफल हुने पुष्टि गर्नुहोस्। कुनै पनि परिस्थितिमा आपतकालीन कललाई परीक्षण मामिला बनाउनु हुँदैन। त्यसपछि जारी भएको नियम जाँच्नुहोस्, किनभने शून्यमा अड्किएको काउन्टर अपवाद कहिल्यै मिलेन भन्ने सबैभन्दा छिटो प्रमाण हो:

nft -a list chain inet edge forward

परीक्षणमा पुनः जडान वा नेटवर्क परिवर्तन समावेश गर्नुहोस्, र फोन पहिले नै जोडिएको हुनुभन्दा नेटवर्कमा सामेल हुने चिसो सुरुवातबाट दोहोर्याउनुहोस्। कल असफल भइरहँदा काउन्टर सर्छ भने समस्या फायरवाल छोडेर वाहकको गन्तव्य सूचीमा पुगेको छ।