फ़ोन की 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

परीक्षण में पुन: कनेक्शन या नेटवर्क परिवर्तन शामिल करें, और इसे ठंडी शुरुआत से दोहराएँ जहाँ फ़ोन नेटवर्क से जुड़ता है, पहले से जुड़ा हुआ नहीं। यदि कॉल विफल रहते हुए काउंटर आगे बढ़े, तो समस्या फ़ायरवॉल से निकल चुकी है और ऑपरेटर की गंतव्य सूची की है।