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 सेवा के लिए, ऐसे क्लाइंट से दोहराएँ जो कभी कनेक्ट नहीं हुआ, क्योंकि फिर से शुरू हुआ सत्र ऐसी अवस्था दोबारा उपयोग कर सकता है जिस पर नए सत्र को बातचीत करनी पड़ती है। जो नियम-समूह पास हुआ उसे ठीक-ठीक दर्ज करें, चेकसम या प्रति के साथ, ताकि बाद का संपादन अनुमान के बजाय तुलना किया जा सके। नियमों के क्रम के स्वामी के साथ समन्वय करें, क्योंकि पहले का नियम आपके जोड़े गए नियम पर चुपचाप जीत जाता है।