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