OpenVPN के लिए macOS pf किल स्विच: बंद होने वाले नियम

macOS पर एक किल स्विच उतना ही अच्छा होता है जितनी उसके पीछे की पैकेट फ़िल्टर नीति, और pf वह हिस्सा है जो उस नीति को लागू करता है। नीति को एक साथ दो उलटे काम करने होते हैं: क्लाइंट को उसके सर्वर तक पहुँचने देना ताकि सुरंग बन सके, और बाकी सबको सीधे बाहर जाने से रोकना। ज़्यादातर प्रकाशित नियम-सेट दूसरा काम कर लेते हैं और पहला भूल जाते हैं, इसलिए मशीन सुरक्षा पाने के बजाय कनेक्टिविटी खो देती है। जो संस्करण काम करता है वह अंतिम छोर, रिज़ॉल्वर और सुरंग का नाम लेता है, और इससे ज़्यादा कुछ नहीं।

पैकेट फ़िल्टर क्या तय कर सकता है, और क्या नहीं

pf इंटरफ़ेस, पते, प्रोटोकॉल नंबर और पोर्ट देखता है, और वहीं रुक जाता है। यह कभी नहीं जानता कि किस प्रक्रिया ने सॉकेट खोला, इसलिए एक प्रोग्राम के लिए लिखी अनुमति उस हर प्रोग्राम की अनुमति बन जाती है जो उसी पोर्ट तक पहुँच सकता है। इसी तरह एक उदार UDP अपवाद किल स्विच को फिर सामान्य नेटवर्क में बदल देता है। एप्लिकेशन-सचेत ब्लॉकिंग क्लाइंट या सिस्टम एक्सटेंशन का काम है, इस फ़ाइल का नहीं।

फ़िल्टर रूट भी नहीं बनाता। जब क्लाइंट गिरता है, डिफ़ॉल्ट रूट अब भी किसी मृत सुरंग की ओर इशारा कर सकता है, और pf उसे Wi-Fi पर चुपचाप लौटने के बजाय अवरुद्ध पैकेटों में बदल देता है। रोक ही इच्छित नतीजा है, टालने लायक खराबी नहीं।

क्रम नियम के पाठ से ज़्यादा बार नतीजा तय करता है। quick के बिना pf मेल के बाद भी मूल्यांकन करता रहता है और अंतिम मेल खाता नियम जीतता है, इसलिए नीचे की ओर एक चौड़ा पास ऊपर के सावधान अपवादों को रद्द कर देता है। पासों को quick चिह्नित करने से पहला मेल अंतिम हो जाता है, और नीति लेखक आम तौर पर यही चाहता है।

पहले इंटरफ़ेस और अंतिम छोर के तथ्य पढ़ें

हर Mac पर वायरलेस इंटरफ़ेस एक जैसे क्रमांकित नहीं होते, और सुरंग उपकरण को ऐसा नंबर मिलता है जो बूट के बीच बदल सकता है। जो नियम ऐसे उपकरण का नाम लेता है जो मौजूद नहीं है वह पार्स होते समय विफल हो जाता है, जो शोरगुल वाला और पकड़ना आसान है, जबकि गलत मौजूदा उपकरण का नाम लेने वाला नियम साफ़ पार्स होता है और उस ट्रैफ़िक की अनुमति देता है जिसे आप रोकना चाहते थे।

तथ्य तब इकट्ठा करें जब क्लाइंट जुड़ा हो, क्योंकि सुरंग उपकरण तभी मौजूद होता है। आपको वह इंटरफ़ेस चाहिए जो डिफ़ॉल्ट रूट रखता है, क्लाइंट द्वारा बनाया गया उपकरण, और उस सर्वर का पता और पोर्ट जिसे वह डायल करता है। वही अंतिम मान वह है जिसे ज़्यादातर नियम-सेट छोड़ देते हैं, और उसे छोड़ना ही वजह है कि कॉपी किया गया सेट अपनी ही सुरंग रोक देता है।

route -n get default
ifconfig -l
scutil --nc list

पहला कमांड उस इंटरफ़ेस का नाम लेता है जो अभी जीत रहा है, दूसरा हर उस उपकरण को सूचीबद्ध करता है जिसे कर्नेल जानता है, और तीसरा वे VPN कॉन्फ़िगरेशन दिखाता है जो सिस्टम शुरू कर सकता है। वे उत्तर लिख लें, फिर क्लाइंट के अपने कॉन्फ़िगरेशन से सर्वर का पता और पोर्ट पढ़ें।

सुरंग के रास्ते के इर्द-गिर्द नियम-सेट लिखें

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

set skip on lo0
block all
pass out quick on utun0
# maintain this line when the server address changes
pass out quick on en1 inet proto udp to 203.0.113.10 port 1194
# only the resolver the client uses before the tunnel exists
pass out quick on en1 inet proto udp to 192.0.2.53 port 53
pass out quick on en1 inet proto udp from any port 68 to any port 67
pass out quick on en1 inet proto udp to 224.0.0.251 port 5353

DHCP पंक्ति इसलिए है क्योंकि Mac पता होने से पहले पता माँगता है, इसलिए अनुरोध पोर्ट 68 से पोर्ट 67 की ओर बिना किसी काम के स्रोत पते के निकलता है। मल्टीकास्ट पंक्ति सिस्टम को यह तय करने देती है कि वायरलेस लिंक इस्तेमाल लायक है या नहीं, और इसे हटाने से ऐसी मशीन बनती है जो चालू नेटवर्क पर कोई कनेक्शन न होने की सूचना देती है। अंतिम छोर की पंक्ति वह है जो OpenVPN को उसके सर्वर तक पहुँचने देती है; इसके बिना block all बाहरी हैंडशेक गिरा देता है और सुरंग कभी ऊपर नहीं आती। रिज़ॉल्वर की पंक्ति सामान्य DNS अनुमति से संकरी है, क्योंकि यह मशीन के हर प्रश्न के बजाय एक पता और एक पोर्ट का नाम लेती है।

वे अंतिम छोर और रिज़ॉल्वर अपवाद ही दो हैं जो मौजूद होने चाहिए; बाकी सब अवरुद्ध रहता है। अगर क्लाइंट शाब्दिक पता डायल करता है, तो रिज़ॉल्वर पंक्ति हटा दें और अंतिम छोर की पंक्ति रखें। अगर सर्वर का पता बदले, तो अगले कनेक्शन से पहले उस पंक्ति को अपडेट करें, या क्लाइंट के अपने हुक से pf तालिका भरें और इसके बजाय तालिका का मिलान करें।

सुरंग नीचे उतारें, फिर रीबूट करें

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

sudo pfctl -n -v -f /etc/pf.conf
sudo pfctl -f /etc/pf.conf
sudo pfctl -e
sudo pfctl -s rules
sudo pfctl -s Anchors
sudo pfctl -a <anchor> -s rules
sudo pfctl -s info

नियम लोड होने पर सुरंग नीचे उतारें और कोई पृष्ठ लोड करने का प्रयास करें। सामान्य ट्रैफ़िक रुकना चाहिए, और मशीन के सोने और जागने के बाद भी रुका रहना चाहिए, क्योंकि उसी बदलाव में पुरानी स्थिति वापस आती है। फिर से जुड़ें और पुष्ट करें कि नियम-सेट को छुए बिना ट्रैफ़िक फिर शुरू होता है। अगर सुरंग बंद होने पर भी ब्राउज़र काम करता है, तो कोई नियम आपकी सोच से चौड़ा है, और वापस पढ़ना आम तौर पर उसका नाम बता देता है।

रीबूट वह हिस्सा है जिसे लोग छोड़ देते हैं। macOS बूट पर /etc/pf.conf पढ़ता है, लेकिन फ़ाइल पढ़ना फ़िल्टर चालू करने के बराबर नहीं है, इसलिए अभी काम करने वाला नियम-सेट रीस्टार्ट के बाद निष्क्रिय हो सकता है। इसके बाद sudo pfctl -s info चलाएँ और पुष्ट करें कि स्थिति पंक्ति फ़िल्टर को सक्रिय बताती है।

बाहर निकलने और रीस्टार्ट के रास्ते को ईमानदार रखें

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

sudo pfctl -d
sudo pfctl -f /etc/pf.conf.previous
sudo pfctl -s rules

स्थायित्व के लिए एक लॉन्च डेमन चाहिए जो pfctl -e चलाए और बूट पर आपकी फ़ाइल लोड करे। इसे किसी भी अन्य विशेषाधिकार वाले काम की तरह समझें: पूर्ण पथ, बाद में पढ़ने लायक लॉग, और ऐसी मशीन पर परीक्षण जहाँ आप शारीरिक रूप से पहुँच सकें। चुपचाप विफल होने वाला डेमन मशीन को असुरक्षित और सामान्य दिखने वाला छोड़ देता है।

अंतरालों का दस्तावेज़ बनाएँ, शुरुआत उस दूसरे VPN क्लाइंट से करें जो अपना सुरंग उपकरण बनाता है। आपके नियम एक सुरंग इंटरफ़ेस का नाम लेते हैं, इसलिए दूसरा अवरुद्ध रहता है या बाद में जोड़े गए चौड़े नियम से मेल खा जाता है। टेथरिंग और हॉटस्पॉट इंटरफ़ेस कभी-कभी ही दिखते हैं और उसी टिप्पणी के लायक हैं। इनमें से कोई भी अंतराल नीति छोड़ने की वजह नहीं है; ये वे शर्तें हैं जिनके तहत यह अब भी लागू है।