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 क्लायंटपासून सुरुवात करा। तुमचे नियम एका सुरंग इंटरफेसचे नाव घेतात, त्यामुळे दुसरे अडवलेले राहते किंवा नंतर जोडलेल्या रुंद नियमाला जुळते। टेथरिंग आणि हॉटस्पॉट इंटरफेस कधीकधीच दिसतात आणि त्याच टिप्पणीला पात्र आहेत। या अंतरालांपैकी कोणतेही धोरण वगळण्याचे कारण नाही; ह्या त्या अटी आहेत ज्यांत ते अजूनही लागू आहे।