VPN पडल्यावर काहीही गळू नये म्हणून Linux चा इग्रेस कसा लॉक करावा

घरच्या अपलिंकवरील मीडिया बॉक्सची कल्पना करा, ज्याला इंटरनेटपर्यंत फक्त टनेलमधूनच पोहोचायचे आहे. टनेल पडल्यावर अ‍ॅप्लिकेशनने भौतिक इंटरफेसवर गुपचूप चालू राहण्याऐवजी थांबले पाहिजे. हे वर्तन मिळवणे ही राउटिंगची नव्हे, तर फायरवॉलची समस्या आहे, आणि हा फरक महत्त्वाचा आहे कारण रूट डेमन रीस्टार्टने बदलता येतो, पण फिल्टर तुम्ही ठेवलेल्या जागीच राहतो. पुढे पाहू की पॅकेटचा मार्ग प्रत्यक्षात कसा ठरवतो, आणि नंतर टनेलला पुन्हा जोडणारे अपवाद कसे मर्यादित करावे.

स्थानिक आउटपुट फॉरवर्डिंगपेक्षा वेगळा हुक आहे

मशीनवरील अ‍ॅप्लिकेशनमधून बाहेर पडणारा पॅकेट आउटपुट हुकमधून जातो; मशीन दुसऱ्या होस्टसाठी राउट करते तो पॅकेट फॉरवर्डमधून जातो. फक्त forward चा उल्लेख करणारे धोरण दुसरे मर्यादित करते आणि पहिले पूर्णपणे खुले ठेवते, म्हणूनच इतके इग्रेस लॉक बरोबर दिसतात आणि काहीच करत नाहीत. इंटरफेस जुळणीही त्याच नियमात येते: oifname "tun0" accept आधीच टनेलमधून राउट झालेला ट्रॅफिक पुढे जाऊ देते. राउटिंग आणि फिल्टरिंगही वेगळे निर्णय राहतात, म्हणून फिल्टर पॅकेट नाकारत असतानाही अपलिंक रूट असू शकतो. तुम्ही याच विभाजनावर विसंबून आहात.

इतर उपकरणांसाठी फॉरवर्ड करणाऱ्या गेटवेला दोन्ही हुक लागतात. फक्त आउटपुट लॉक केल्यास मशीनचेच संरक्षण होते आणि खालील प्रत्येक क्लायंटला गळण्याची मुभा मिळते.

अपवादांची यादी एंडपॉइंटपासून बाहेरच्या दिशेने लिहा

टनेलच्या एंडपॉइंटपासून सुरुवात करा: एक गंतव्य पत्ता किंवा लहान मंजूर संच, ट्रान्सपोर्ट प्रोटोकॉल आणि गंतव्य पोर्ट, उदाहरणार्थ udp dport 1194 ip daddr 203.0.113.7 accept. क्लायंट होस्टनेम रिझोल्व्ह करत असेल तर सुरुवातीच्या DNS देवाणघेवाणीला रिझोल्व्हर आणि पोर्ट 53 पर्यंत मर्यादित स्वतःचा नियम लागतो, त्या रिझोल्व्हरच्या पत्त्याला सर्वसाधारण परवानगी नाही. प्रत्येक अपवादाने तो का आहे हे कारण सांगावे. VPN पोर्टवरील सर्व UDP ट्रॅफिकला परवानगी हे तुमच्या मनातील एका प्रमाणित सेवेपेक्षा खूप जास्त झाकते.

सुरुवातीचे रिझोल्व्हिंग हीच लॉक सहसा कुजतात ती जागा. टाइमरवर रिफ्रेश होणाऱ्या पत्त्यांच्या संचाला रिफ्रेश अयशस्वी झाल्यावर निश्चित वर्तन लागते, आणि ते वर्तन यशस्वी होईपर्यंत लिंक उघडणे नसावे. टनेल सुरू असताना टनेलमधून रिफ्रेश करा, अन्यथा शेवटच्या ज्ञात निरोगी एंडपॉइंटवर परत जा.

स्थानिक प्रशासनालाही तोच दृष्टिकोन लागतो. व्यवस्थापन सबनेट फक्त त्याचे पत्ते खाजगी आहेत म्हणून विश्वासार्ह नाही, आणि त्यावर विश्वास ठेवणारा नियम लॉकभोवती दुसरा मार्ग बोलावतो.

इंटरफेस जुळणी निरोगी टनेलचा पुरावा नाही

tun0 मधून बाहेर जाणारे सर्व स्वीकारणारे नियम गृहीत धरतात की त्या इंटरफेसवरील पॅकेट टनेलमधून आले आहे. इंटरफेसची नावे पुन्हा तयार होतात, आणि नाव ही क्रिप्टोग्राफिक ओळख नाही. इंटरफेस सुरू असतानाही पीअर गेलेला असू शकतो, ज्यामुळे नियम अत्यंत विश्वासार्ह निष्क्रियता बनतो.

कनेक्शन ट्रॅकिंग संबंधित सापळा जोडते. स्थापित कनेक्शनसाठीचा विस्तृत नियम फ्लोला आधी मिळालेली परवानगी पुन्हा चालवतो, म्हणून टनेल पडण्यापूर्वी सुरू झालेले सत्र नंतरही चालू राहते. स्टेटवर आधारित स्वीकृती तुम्हाला खरोखर अभिप्रेत असलेल्या इंटरफेस आणि पत्त्यांपुरती मर्यादित ठेवा, अन्यथा स्वतः उघडणारा लॉक बांधला आहे. इनपुट आणि आउटपुट नियमही वेगळ्या प्रश्नांची उत्तरे देतात, आणि एक कडक करून दुसरा दुर्लक्षित ठेवल्यास मशीन तुम्ही विचार न केलेल्या दिशेने पोहोचण्यायोग्य राहते.

डेमन क्रॅशनंतर काय टिकते

टनेल वर आल्यानंतर चालणारी स्क्रिप्ट बसवते तो फिल्टर टनेलसोबतच नाहीसा होतो, तो जेव्हा लागत होता त्या क्षणीच. लॉक बूटवेळी लोड करा आणि डेमनला फक्त त्याचे अपवाद सांभाळू द्या.

डीफॉल्ट रूट हटवणेही पर्याय नाही. रूट ही डेमनच्या मालकीची आणि तो पुन्हा लिहिणारी स्थिती आहे, आणि ती काढल्यास पुन्हा जोडण्यासाठी लागणारा मार्गही जाऊ शकतो. IPv6 ला स्वतःची योजना लागते, कारण शेजारी शोध आणि राउटर जाहिराती या दुवा सेवा आहेत ज्या सामान्य ट्रॅफिक ब्लॉक असतानाही चालू राहिल्या पाहिजेत. DHCP ही त्याच श्रेणीत येते. या गोष्टी नंतर व्यत्यय म्हणून शोधण्याऐवजी हेतू असलेले अपवाद म्हणून लिहून ठेवा.

तैनातीपूर्वीचा पुनर्प्राप्ती मार्ग

लॉक जसा अयशस्वी होईल तसाच तपासा: टनेलशिवाय बूट, डेमन मारणे, एंडपॉइंट बदलणे आणि पुन्हा जोडणे. प्रत्येक बाबतीत अ‍ॅप्लिकेशन थांबले पाहिजेत आणि पुनर्प्राप्ती वाहिनी चालू राहिली पाहिजे. हे कन्सोलवरून करा, कारण रिमोट शेल हेच तुमच्या स्वतःच्या नियमाने सर्वात जास्त लॉक होण्याची शक्यता असलेले सत्र आहे.

मग सामान्य अ‍ॅप्लिकेशन अजून कुठपर्यंत पोहोचू शकते ते तपासा, निरुपद्रवी गंतव्य आणि तपासता येण्याजोगी विनंती वापरून. तुम्हाला हवा असलेला निकाल म्हणजे अपलिंकवर नकार आणि टनेलमधून यश, दोन्हीपैकी काहीही असू शकणारा संदिग्ध टाइमआउट नाही. नियमांचा संच शेल स्क्रिप्टमधून संपूर्ण तक्ता बदलण्याऐवजी फायरवॉलच्या उर्वरित भागाच्याच मालकीखाली ठेवा. प्रत्येक परवानगी स्वतःचे समर्थन करू शकणारे धोरण, कोणीही समजावून सांगू न शकणाऱ्या लांब नियमसंचापेक्षा अधिक मूल्यवान आहे.