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