फोनचे 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

चाचणीत पुन्हा जोडणी किंवा नेटवर्क बदल समाविष्ट करा, आणि फोन आधीच जोडलेला असण्याऐवजी नेटवर्कमध्ये सामील होणाऱ्या थंड सुरुवातीपासून त्याची पुनरावृत्ती करा. कॉल अयशस्वी होत असताना काउंटर हलत असेल, तर समस्या फायरवॉल सोडून ऑपरेटरच्या गंतव्य यादीत गेली आहे.