VPN खस्दा केही पनि नचुहावट होस् भनेर Linux को इग्रेस कसरी लक गर्ने
राउटिङ र फिल्टरिङ छुट्टै निर्णय हुन्। आउटपुट हुक लक गर्नुहोस्, त्यसपछि टनेल पुनः जोडिन आवश्यक एन्डपोइन्ट, DNS र प्रशासनिक अपवादहरू सीमित गर्नुहोस्।
घरको अपलिंकमा रहेको मिडिया बक्सको कल्पना गर्नुहोस्, जसले इन्टरनेटमा टनेलबाट मात्र पुग्नुपर्छ। टनेल खस्दा अनुप्रयोगले भौतिक इन्टरफेसबाट चुपचाप चलिरहनुको सट्टा रोकिनुपर्छ। यो व्यवहार पाउनु राउटिङको होइन, फायरवालको समस्या हो, र यो भिन्नता महत्त्वपूर्ण छ किनकि रुट डेमन रिस्टार्टले फेर्न सकिन्छ, तर फिल्टर तपाईंले राखेकै ठाउँमा रहन्छ। अब प्याकेटको बाटोले वास्तवमा कसरी निर्णय गर्छ, र त्यसपछि टनेललाई पुनः जोडिराख्ने अपवादहरू कसरी सीमित गर्ने भन्ने हेर्नेछौं।
स्थानीय आउटपुट फर्वार्डिङभन्दा फरक हुक हो
मेसिनको अनुप्रयोगबाट बाहिर जाने प्याकेट आउटपुट हुकबाट जान्छ; मेसिनले अर्को होस्टका लागि रुट गर्ने प्याकेट फर्वार्डबाट जान्छ। forward मात्र उल्लेख गर्ने नीतिले दोस्रोलाई सीमित गर्छ र पहिलोलाई पूरै खुला छाड्छ, त्यसैले धेरै इग्रेस लक सही देखिन्छन् र केही गर्दैनन्। इन्टरफेस मिलान पनि त्यही नियममा पर्छ: oifname "tun0" accept पहिले नै टनेलबाट रुट भइसकेको ट्राफिक जान दिन्छ। राउटिङ र फिल्टरिङ पनि छुट्टै निर्णय रहन्छन्, त्यसैले फिल्टरले प्याकेट अस्वीकार गर्दा पनि अपलिंक रुट रहन सक्छ। तपाईं यही विभाजनमा भर पर्नुहुन्छ।
अन्य यन्त्रका लागि फर्वार्ड गर्ने गेटवेलाई दुवै हुक चाहिन्छ। आउटपुट मात्र लक गर्दा मेसिन आफैं सुरक्षित हुन्छ र तलको हरेक क्लाइन्टलाई चुहावटको स्वतन्त्रता मिल्छ।
अपवादको सूची एन्डपोइन्टबाट बाहिरतिर लेख्नुहोस्
टनेलको एन्डपोइन्टबाट सुरु गर्नुहोस्: एउटा गन्तव्य ठेगाना वा सानो स्वीकृत समूह, ट्रान्सपोर्ट प्रोटोकल र गन्तव्य पोर्ट, जस्तै udp dport 1194 ip daddr 203.0.113.7 accept। क्लाइन्टले होस्टनाम रिजोल्भ गर्छ भने सुरुवाती DNS आदानप्रदानलाई रिजोल्भर र पोर्ट 53 मा सीमित आफ्नै नियम चाहिन्छ, त्यो रिजोल्भरको ठेगानामा खुला अनुमति होइन। हरेक अपवादले आफू किन छ भन्ने कारण बताउनुपर्छ। VPN पोर्टमा सबै UDP ट्राफिकको अनुमति तपाईंको मनमा रहेको त्यो एउटा प्रमाणित सेवाभन्दा धेरै बढी ढाक्छ।
सुरुवाती रिजोल्भिङ नै त्यो ठाउँ हो जहाँ लक सड्छन्। टाइमरमा रिफ्रेस हुने ठेगानाको समूहलाई रिफ्रेस असफल हुँदा निर्धारित व्यवहार चाहिन्छ, र त्यो व्यवहार सफल नहुञ्जेल लिंक खोल्नु हुँदैन। टनेल उठेको बेला टनेलबाट रिफ्रेस गर्नुहोस्, अन्यथा अन्तिम ज्ञात स्वस्थ एन्डपोइन्टमा फर्कनुहोस्।
स्थानीय प्रशासनलाई पनि त्यही व्यवहार चाहिन्छ। व्यवस्थापन सबनेटका ठेगाना निजी छन् भन्दैमा विश्वसनीय हुँदैन, र त्यसमा भर पर्ने नियमले लकको वरिपरि दोस्रो बाटो बोलाउँछ।
इन्टरफेस मिलान स्वस्थ टनेलको प्रमाण होइन
tun0 बाट बाहिर जाने सबै स्वीकार गर्ने नियमहरूले त्यो इन्टरफेसमा रहेको प्याकेट टनेलबाट आएको मान्छन्। इन्टरफेसका नाम फेरि बन्छन्, र नाम क्रिप्टोग्राफिक पहिचान होइन। इन्टरफेस उठिरहेकै बेला पियर गइसकेको हुन सक्छ, जसले नियमलाई धेरै विश्वसनीय निष्क्रियता बनाउँछ।
कनेक्सन ट्र्याकिङले सम्बन्धित जाल थप्छ। स्थापित कनेक्सनका लागि फराकिलो नियमले फ्लोले पहिले पाएको अनुमति फेरि चलाउँछ, त्यसैले टनेल खस्नुअघि सुरु भएको सत्र पछि पनि चलिरहन्छ। स्टेटमा आधारित स्वीकृति तपाईंले साँच्चै भन्न खोजेका इन्टरफेस र ठेगानामा मात्र सीमित गर्नुहोस्, नत्र आफैं खुल्ने लक बनाउनुभयो। इनपुट र आउटपुट नियमले पनि फरक प्रश्नको उत्तर दिन्छन्, र एउटा कडा पारेर अर्को बेवास्ता गर्दा मेसिन तपाईंले नसोचेको दिशाबाट पुग्न सकिने रहन्छ।
डेमन क्र्यासबाट के बाँच्छ
टनेल उठेपछि चल्ने स्क्रिप्टले राख्ने फिल्टर टनेलसँगै हराउँछ, ठ्याक्कै जब त्यो चाहिएको थियो त्यही क्षणमा। लक बुटमा लोड गर्नुहोस् र डेमनलाई यसका अपवाद मात्र सम्हाल्न दिनुहोस्।
पूर्वनिर्धारित रुट मेटाउनु पनि विकल्प होइन। रुट त्यो अवस्था हो जसको मालिक डेमन हो र जसलाई उसले फेरि लेख्छ, र त्यो हटाउँदा पुनः जोडिन आवश्यक बाटो पनि जान सक्छ। IPv6 लाई आफ्नै योजना चाहिन्छ, किनकि छिमेकी पत्ता लगाउने र राउटर घोषणाहरू लिंक सेवा हुन् जुन सामान्य ट्राफिक अवरुद्ध हुँदा पनि चलिरहनुपर्छ। DHCP पनि त्यही श्रेणीमा पर्छ। यिनलाई पछि अवरोधका रूपमा पत्ता लगाउनुको सट्टा उद्देश्यसहितका अपवादका रूपमा लेख्नुहोस्।
तैनाथी अघिको पुनर्प्राप्ति मार्ग
लक जसरी असफल हुन्छ त्यसरी नै परीक्षण गर्नुहोस्: टनेल बिना बुट, डेमन मार्ने, एन्डपोइन्ट फेर्ने र पुनः जोडिने। हरेक अवस्थामा अनुप्रयोग रोकिनुपर्छ र पुनर्प्राप्ति च्यानल चलिरहनुपर्छ। यो कन्सोलबाट गर्नुहोस्, किनकि रिमोट शेल नै तपाईंको आफ्नै नियमले सबैभन्दा बढी लक हुने सम्भावना भएको सत्र हो।
त्यसपछि सामान्य अनुप्रयोग अझै कहाँ पुग्न सक्छ हेर्नुहोस्, हानिरहित गन्तव्य र जाँच्न सकिने अनुरोधसँग। तपाईंले चाहेको नतिजा अपलिंकमा अस्वीकार र टनेलबाट सफलता हो, दुवै अर्थ लाग्न सक्ने अस्पष्ट टाइमआउट होइन। नियमको सेट फायरवालको बाँकी भागकै मालिकत्वमुनि राख्नुहोस्, शेल स्क्रिप्टबाट पूरै तालिका फेर्नुको सट्टा। जहाँ हरेक अनुमतिले आफैंलाई न्यायोचित ठहराउन सक्छ त्यो नीति, कसैले पनि व्याख्या गर्न नसक्ने लामो नियमसँगभन्दा बढी मूल्यवान छ।