SSH आणि VPN इनग्रेस नियम: अनुमती-यादी प्रत्यक्षात काय नियंत्रित करते

नियम बदलण्यापूर्वी एकदा कनेक्ट करा आणि क्लायंट अडकतो की लगेच नाकारला जातो ते नोंदवा. हाच एक फरक कोणत्या निर्णयाने पॅकेट टाकले हे सांगतो आणि धोरण फाइल्स वाचण्याचा एक तास वाचवतो. उर्वरित प्रवास छोटा आहे: पॅकेट एक हुक ओलांडते, नियमाशी जुळते आणि एकतर श्रोत्यापर्यंत पोहोचते किंवा पोहोचत नाही. अनुमती-यादी त्या तीन तथ्यांभोवतीचे हिशोब ठेवणे एवढेच आहे.

एक SSH प्रयत्न इनपुट हुकपर्यंत अनुसरा

क्लायंट होस्टच्या पत्त्यावर पोर्ट 22 वर SYN पाठवतो, आणि कर्नेल ठरवते की ते पॅकेट स्थानिक सेवेसाठी आहे का. असल्यास इनपुट मार्ग चालतो आणि नियम-संच ते पॅकेट स्वीकारतो किंवा टाकून देतो. शांतता म्हणजे श्रोत्याने पाहण्यापूर्वीच SYN मरण पावले, तर झटपट नकार म्हणजे कशाने तरी रीसेटसह उत्तर दिले. हे वेगवेगळ्या नियमांचे वेगवेगळे निर्णय आहेत आणि दोन्ही वैध परिणाम आहेत.

नंतर श्रोत्याची खात्री करा, कारण नसलेल्या सेवेला कोणताही नियम वाचवू शकत नाही. ss -ltnp चालवा आणि तुम्ही अपेक्षित असलेल्या पोर्ट व पत्ता-कुटुंबाशी काही बांधलेले आहे का ते तपासा, नंतर क्लायंटवर ssh -v वाचून ते कुठे थांबते ते पाहा.

फॉरवर्डिंग हा वेगळा निर्णय आहे

VPN सर्व्हरवर अधिक मनोरंजक हुक forward आहे, कारण क्लायंटची रहदारी मशीनला सुपूर्द करण्याऐवजी तिच्यातून मार्गस्थ होते. फक्त स्वतःचा VPN क्लायंट चालवणाऱ्या होस्टला इतरांची पॅकेट्स पुढे पाठवणाऱ्या होस्टपेक्षा खूप लहान नियम-संच लागतो. दोन्ही रचना एकाच मशीनवर मिसळल्यास बरोबर दिसणारे आणि काहीही पुढे न सोडणारे नियम तयार होतात.

आंतरिक धोरण स्वतंत्र प्रश्न म्हणून लिहा: कोणते क्लायंट पत्ते बोगद्यातून कोणत्या गंतव्यांपर्यंत पोहोचू शकतात. प्रशासकीय मार्ग, उदाहरणार्थ SSH, स्वतःच्या स्रोत-निर्बंधासह इनपुट मार्गावर ठेवा. चाचणीदरम्यान जोडलेला सैल forward नियम हाच चाचणीपेक्षा जास्त टिकणारा क्लासिक दोष आहे, म्हणून बदलानंतर तुम्ही संपादित केलेली एक ओळ नव्हे तर संपूर्ण संच तपासा. बोगद्याचा श्रोता उघडणे म्हणजे प्रत्येक जोडलेल्या क्लायंटला होस्ट सांभाळण्याची परवानगी नाही.

ड्रॉप आणि रिजेक्ट क्रिया आहेत, धोरणे नाहीत

बेस चेनचे धोरण स्वीकारते किंवा टाकून देते आणि पर्यायांची संपूर्ण यादी एवढीच, जसे nftables संदर्भ सांगतो. रिजेक्ट निवडलेल्या उत्तरासह नियम-क्रिया म्हणून अस्तित्वात आहे, म्हणूनच ते धोरण म्हणून लिहिणे nftables आणि iptables दोन्हीवर अपयशी ठरते. प्रत्यक्षात drop क्लायंटला कोणतीही माहिती देत नाही, तर reject त्याला ज्यावर कार्य करता येईल अशी त्रुटी देतो.

table inet admin {
    chain input {
        type filter hook input priority filter; policy drop;
        ct state established,related accept
        ip saddr 203.0.113.0/28 tcp dport 22 accept
        udp dport 51820 accept
        icmp type { destination-unreachable, time-exceeded } accept
    }
}

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

प्रत्यक्षात लागणारी नियंत्रण रहदारी ठेवा

सर्व ICMP अवरोधित करणे हे मार्गाच्या MTU शोधनास तोडणारे लोकप्रिय डीफॉल्ट आहे, आणि लक्षण म्हणजे स्थापन होऊन नंतर मोठ्या पॅकेटवर अडकणारे कनेक्शन. IPv6 वर शेजारी शोधन त्याच्या स्वतःच्या ICMPv6 प्रकारांवर अवलंबून आहे, आणि ते टाकून दिल्यास कोणताही TCP नियम पाहण्यापूर्वीच दुवा तुटतो. दोन्ही सर्वव्यापी परवानग्या म्हणून नव्हे तर नामांकित अवलंबित्व म्हणून अनुमती-यादीत येतात. शोधन शांतपणे तोडणारे धोरण थोडी निदान रहदारी स्वीकारणाऱ्या धोरणापेक्षा वाईट आहे.

तुम्ही सुरू केलेल्या कनेक्शनसाठी established आणि related स्थितीची परवानगी द्या, आणि उत्तरे स्थिती-जाणणाऱ्या इंजिनवर सोडा. नंतर खात्री करा की उत्तराचा मार्ग पुढे अवरोधित नाही, कारण वरच्या बाजूला केवळ बाहेर जाणाऱ्या रहदारीवरील निर्बंध तोच टाइमआउट निर्माण करतो ज्याचा दोष तुम्ही होस्टवर घालणार होते.

जुना मार्ग सोडण्यापूर्वी पुनर्प्राप्ती सिद्ध करा

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

VPN सेवेसाठी, कधीही कनेक्ट न केलेल्या क्लायंटपासून पुनरावृत्ती करा, कारण पुन्हा सुरू झालेले सत्र नव्या सत्राने वाटाघाटी करावयाची स्थिती पुन्हा वापरू शकते. जो नियम-संच पास झाला तो नेमका नोंदवा, चेकसम किंवा प्रतीसह, जेणेकरून पुढील संपादन अंदाजाऐवजी तुलना करता येईल. नियमांच्या क्रमाच्या मालकाशी समन्वय साधा, कारण आधीचा नियम तुम्ही जोडलेल्या नियमावर शांतपणे जिंकतो.