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 ग्राहकबाट सुरु गर्नुहोस्। तपाईंका नियमहरूले एउटा सुरुङ इन्टरफेसको नाम लिन्छन्, त्यसैले दोस्रो रोकिएको रहन्छ वा पछि थपिएको फराकिलो नियमले समात्छ। टेथरिङ र हटस्पट इन्टरफेस कहिलेकाहीँ मात्र देखिन्छन् र त्यही टिप्पणीको योग्य छन्। ती अन्तरालमध्ये कुनै पनि नीति छोड्ने कारण होइन; ती त्यस्ता सर्त हुन् जसमा यो अझै लागू हुन्छ।