Mac पर PF VPN लॉक: एक साइट नीति, न कि वितरण-योग्य सुविधा
Packet Filter वितरित उत्पादों के लिए समर्थित API नहीं है। नियम-समूह को एक स्वामी दें, हर अपवाद का नाम दें और संक्रमणों का परीक्षण करें।
यह आपके Mac पर काम करता है, इसलिए यह ऐसा लगता है जिसे आप उपयोगकर्ताओं को दे सकते हैं। यही धारणा पहली चीज़ है जिसे छोड़ना है। Apple का TN3165 स्पष्ट कहता है कि Packet Filter आम तौर पर वितरित उत्पादों के लिए समर्थित API नहीं है, और विशेषाधिकार-प्राप्त, नियंत्रित साइट प्रशासन को उचित मामला मानता है। इसलिए PF पर बना VPN लॉक एक स्थानीय परिचालन नीति है जिसका एक स्वामी है, ऐसी सुविधा नहीं जिसे आप किसी ऐप के भीतर वितरित कर सकें।
PF पैकेजिंग सतह नहीं है
यह अंतर अकादमिक नहीं है। PF पर निर्भर वितरित उत्पाद Apple द्वारा उसमें किए गए हर बदलाव को विरासत में लेता है, किसी अन्य उपकरण से हर टकराव को भी जो नियम लिखता है, और इस बात का कोई समर्थन वादा नहीं मिलता कि यह व्यवस्था चलती रहेगी। जो साइट अपनी मशीनों का प्रशासन स्वयं करती है उसका संबंध अलग है: वह इस निर्भरता का दस्तावेज़ बना सकती है, हर OS रिलीज़ के विरुद्ध परीक्षण कर सकती है और रखरखाव स्वीकार कर सकती है।
कुछ इंस्टॉलेशन सलाह एक ऐसी सीमा पार करती हैं जिसका नाम देना उचित है। एक एंकर लोड होने के लिए पूरे सिस्टम नियम-समूह को अधिलेखित करना, Apple के सिस्टम लॉन्च कॉन्फ़िगरेशन को संपादित करना, या System Integrity Protection अक्षम करना पुनः प्रयोग योग्य रेसिपी के लिए स्वीकार्य आवश्यकताएँ नहीं हैं। यदि किसी प्रकाशित मार्गदर्शिका को इनमें से कोई भी चाहिए, तो वह किसी प्रयोगशाला का वर्णन कर रही है, तैनात करने योग्य नीति का नहीं।
वाक्य-रचना से पहले बाहर जाने का इरादा लिखें
एक भी कीवर्ड चुनने से पहले तय करें कि क्या अनुमत है। सामान्यतः तीन मार्ग होने चाहिए: VPN क्लाइंट का अपने सर्वर तक अपना परिवहन, सुरंग के भीतर संरक्षित एप्लिकेशन ट्रैफ़िक, और वह सब जिसे सेटअप या स्थानीय सेवाओं को वास्तव में सीधा मार्ग चाहिए।
हर प्रस्तावित अपवाद को एक गंतव्य, एक परिवहन और एक स्वामी दें। किसी एक एंडपॉइंट तक सभी पोर्ट की अनुमति उस एक परिवहन से कहीं अधिक देती है जो सुरंग उपयोग करती है, और अतिरिक्त जोखिम बिना किसी निर्णय के आ जाता है कि ऐसा होना चाहिए। सार्वजनिक रिज़ॉल्वर की अनुमति अधिक मैत्रीपूर्ण वेश में वही जाल है: यह सुरंग बंद होने पर भी सीधा DNS मार्ग बनाता है, इसलिए नाम खोज अब भी लीक होती है।
| Path | Destination | Owner |
|---|---|---|
| VPN transport | Gateway address, one UDP port | Network team |
| Tunnel traffic | Internal prefixes | Application owner |
| Resolver exception | Named internal resolver | Security team |
अपवाद के लिए उपयोगी परीक्षण यह है कि क्या आप उस व्यक्ति का नाम बता सकते हैं जिसने इसे माँगा और उस विफलता का भी जिसे यह रोकता है। यदि दोनों में से कोई उत्तर नहीं है, तो नियम संभवतः किसी गलत कॉन्फ़िगरेशन का घुमावदार रास्ता है जो अन्यथा अदृश्य रह जाता।
utun नंबर कोई पहचान नहीं हैं
MacOS सुरंग इंटरफ़ेस को utun उपकरणों के रूप में बनाता है, और आपके VPN को दिया गया नंबर स्थिर नहीं है रीबूट, पुनःकनेक्शन या किसी अन्य क्लाइंट की उपस्थिति के दौरान। कुछ अनुमानित नंबरों की सूची देने वाला नियम नीति नहीं है; वह एक दोपहर का स्नैपशॉट है।
नियम को उस चीज़ पर टिकाएँ जो इच्छित प्रदाता की पहचान करे: सुरंग द्वारा आवंटित पता योजना, इंटरफ़ेस का स्वामी प्रक्रिया, या वह कॉन्फ़िगरेशन जिसे VPN क्लाइंट स्वयं बनाए रखता है। फिर दर्ज करें कि वह पहचान कैसे काम करती है, क्योंकि एक साल बाद नियम की समीक्षा करने वाले के पास आपका शेल इतिहास नहीं होगा।
लोड की गई नीति को आरोपणीय बनाएँ
एंकर नाम नियमों को व्यवस्थित करता है; यह सिद्ध नहीं करता कि प्रभावी नीति वही है जो आप चाहते थे। एंकरों के बीच प्राथमिकता, अन्य सॉफ़्टवेयर द्वारा लोड किए गए नियम, और वर्तमान स्थिति — सभी परिणाम बदल सकते हैं। उस मशीन पर PF रखने वाले हर किसी के साथ प्रभावी समूह की समीक्षा करें, और स्वामित्व को उसी स्थान पर दस्तावेज़ करें जहाँ कॉन्फ़िगरेशन है। दो स्वामी अलग-अलग मान्यताओं के साथ अलग-अलग एंकर संपादित करें — यही सामान्य तरीका है जिससे लॉक में छेद बनता है।
नियम-समूह को साइट के समर्थित कॉन्फ़िगरेशन मार्ग में रखें, उसका संस्करण बनाएँ, और लिखें कि कौन-से macOS संस्करण परीक्षण किए गए। हाथ से लागू और एक व्यक्ति द्वारा याद रखा गया बदलाव रखरखाव वाला ढाँचा नहीं है, चाहे फ़ाइल शीर्षक कुछ भी कहे।
संक्रमणों का परीक्षण करें, जुड़ी हुई स्थिति का नहीं
सुरंग चालू रहते लिया गया स्क्रीनशॉट लगभग कुछ भी सिद्ध नहीं करता। इसके बजाय अवस्थाओं से गुजरें: किसी भी कनेक्शन से पहले स्टार्टअप, काम करती सुरंग, बिना चेतावनी गिरने वाली सुरंग, जानबूझकर डिस्कनेक्ट, और Wi-Fi से हॉटस्पॉट तक जाना। हर अवस्था का अपना उत्तर है, और दिलचस्प वे विफलताएँ हैं, न कि सुखद मार्ग।
हर अवस्था में दर्ज करें कि जानबूझकर क्या पहुँच योग्य है। IPv4 और IPv6 अलग-अलग जाँचें, नाम-विश्लेषण का परीक्षण करें, और ऐसा प्रवाह शामिल करें जो संक्रमण से पहले ही स्थापित था, क्योंकि मौजूदा कनेक्शन हमेशा नई नीति का पालन नहीं करते। सुरंग बंद होने पर विफल होने वाला ब्राउज़र एक डेटा बिंदु है, यह प्रमाण नहीं कि हर दूसरा मार्ग अवरुद्ध है।
अंत में, ऐसी रिकवरी विधि रखें जो उस नेटवर्क मार्ग पर निर्भर न हो जिसे आप बदल रहे हैं। स्थानीय संग्रहण पर ज्ञात-अच्छा कॉन्फ़िगरेशन और उसे लोड करने का प्रलेखित तरीका लॉक को नीति में बदल देते हैं; इनके बिना, एक खराब संशोधन प्रशासक को उस मशीन से बाहर कर देता है जिसे सुरक्षित होना था।