iptables: VPN क्लाइन्टहरूलाई एउटै होस्टमा मात्र पुग्न दिनुहोस्

असम्बन्धित देखिने दुई सहयोग टिकटहरू अन्ततः एउटै कारण साझा गर्छन्। पहिलोमा, प्रशासक चाहन्छन् कि सर्भरले टनेलबाट मात्र जडान स्वीकार गरोस्; दोस्रोमा, VPN प्रयोगकर्ताहरू एउटा आन्तरिक होस्टसम्म पुग्नुपर्छ, त्यसभन्दा बढी होइन। दुवै नीति FORWARD मा पर्छन्, र दुवै प्रायः INPUT मा प्रयास गरिन्छ। नतिजा फायरवालजस्तो देखिन्छ र प्लेसहोल्डरजस्तो व्यवहार गर्छ।

कुन चेनले तपाईंको प्रश्नको जवाफ दिन्छ

VPN क्लाइन्टले LAN होस्ट वा त्यसपछि इन्टरनेटतर्फ पठाउने प्याकेटहरू कर्नेलले अगाडि पठाउँछ र तिनीहरू FORWARD मा मूल्याङ्कन हुन्छन्। INPUT र OUTPUT ले सर्भरमै अन्त्य हुने वा त्यहींबाट सुरु हुने ट्राफिक मात्र देख्छन्। त्यसैले tun0 मा नआउने सबै कुरा अस्वीकार गर्दा सर्भरका आफ्नै श्रोताहरूको रक्षा हुन्छ, र स्थापित प्रवाहहरू पहिले स्वीकार नगरिए SSH सत्र पनि अन्त्य हुनेछ। क्लाइन्टहरू कहाँ जान सक्छन् भन्नेमा यसले केही पनि बदल्दैन।

पहिले प्रश्नको नाम राख्नुहोस्: कसले सर्भरसम्म पुग्न सक्छ, वा क्लाइन्टहरू कहाँ जान सक्छन्। धेरैजसो नेटवर्कलाई दुवै जवाफ चाहिन्छ, फरक फरक चेनमा।

पहिले अवस्था, त्यसपछि अनुमति, त्यसपछि अस्वीकृति

अनुमति सूची तब मात्र काम गर्छ जब विशिष्ट अनुमति सामान्य अस्वीकृतिको माथि बस्छ र फिर्ता ट्राफिक दुवैको माथि स्वीकार गरिन्छ। नियमहरू स्पष्ट स्थानमा राख्नुहोस्, त्यसपछि iptables -S FORWARD ले चेन डम्प गर्नुहोस् ताकि क्रम अनुमान नगरी देखियोस्।

POOL=10.99.0.0/24
iptables -I FORWARD 1 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -I FORWARD 2 -s "$POOL" -d 172.31.20.15 -p tcp -m multiport --dports 443,3389 -j ACCEPT
iptables -I FORWARD 3 -s "$POOL" -j REJECT

यो वास्तविक ट्राफिकसँग ठोक्किँदा टिक्छ कि टिक्दैन भन्ने दुई विवरणले निर्धारण गर्छ। अवस्था-नियम नभएमा, भर्खरै अनुमति दिइएका जडानहरूका जवाफहरू आफैं अस्वीकृतिको सामना गरी खारेज हुन्छन्। सीमा नभएको LOG नियमले पहिलो स्क्यानमै सानो विभाजन भरिदिन सक्छ, त्यसैले लगिङ जारी राख्नुअघि -m limit --limit 10/min थप्नुहोस्। REJECT ले तुरुन्तै त्रुटि फर्काउँछ, जुन सूची मिलाउँदा बढी मैत्रीपूर्ण हुन्छ; DROP ले चुपचाप फ्याँक्छ, त्यसैले हरेक गल्ती समय सकिएजस्तो देखिन्छ। जानाजान एउटा छान्नुहोस् र छनोट परिवर्तन अभिलेखमा लेख्नुहोस्।

फर्वार्डिङ र NAT पहिले नै चल्नुपर्छ

फिल्टरिङले मार्ग अस्तित्वमा छ भनी प्रमाणित गर्न सक्दैन। पहिले कर्नेलले बिल्कुल फर्वार्ड गर्छ कि भनी पुष्टि गर्नुहोस्, र यो सेटिङलाई शेलको एकपटकको आदेश नभई स्थायी बनाउनुहोस्। फिल्टर अन्तिम तह हो, पहिलो होइन।

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -s "$POOL" -o eth0 -j MASQUERADE

मास्करेड कहाँ बस्ने भन्ने क्लाइन्टहरू कहाँबाट बाहिरिन्छन् भन्नेमा निर्भर गर्छ। यदि तिनीहरू टनेलबाट टाढाको नेटवर्कतर्फ जान्छन् भने NAT नियम WAN इन्टरफेसमा नभई त्यही इन्टरफेसमा राखिन्छ। त्यसपछि काउन्टर हेर्नुहोस्: POSTROUTING काउन्टर कहिल्यै नसर्दा FORWARD मा स्वीकृतिको संख्या बढ्दै छ भने फिर्ता मार्ग बिग्रिएको छ र फिल्टर ठीक छ। यो पढाइले कहिल्यै समस्या नभएका नियमहरू पुनःलेखन गर्ने एक दिउँसो बचाउँछ।

मेल ब्लक एक चेन पर

INPUT मा पोर्ट 25 ब्लक गर्दा VPN सर्भरलाई पठाइएको मेल मात्र रोकिन्छ। टनेलबाट मेल पठाउने क्षति पुगेको क्लाइन्ट फर्वार्ड हुन्छ, त्यसैले ब्लक 465 र 587 को छेउमा FORWARD मा हुनुपर्छ। यदि एउटा एप्लिकेसनले वैध रूपमा मेल रिले गर्छ भने त्यसको गन्तव्य र पोर्ट त्यो नियमको माथि राख्नुहोस्।

iptables -I FORWARD 2 -s "$POOL" -p tcp -m multiport --dports 25,465,587 -j REJECT

अरू केही कडा गर्नुअघि अस्वीकृति काउन्टरलाई एक हप्ता चल्न दिनुहोस्। बढ्न छोड्ने संख्या नै तपाईंले भर्खरै तोडेको वैध प्रवाह हो।

यसलाई फेरि पढ्नुहोस्, त्यसपछि क्लाइन्टबाट प्रमाणित गर्नुहोस्

नियमसमूह कर्नेलले जस्तो रिपोर्ट गर्छ त्यस्तै पढ्नुहोस्, तपाईंको स्क्रिप्टले लेखेजस्तो होइन। iptables -S FORWARD बाट सुरु गर्नुहोस्, त्यसपछि iptables -t nat -L POSTROUTING -n -v सँग NAT तालिका, त्यसपछि तपाईं जाँचिरहनुभएको प्रवाहको conntrack प्रविष्टि। काम चलिरहेसम्म रोलब्याक आदेश वा निर्धारित फ्लश राख्नुहोस्। हरेक कललाई -w चाहिन्छ, नत्र दुई प्रशासक xtables लकमा ठोक्किन्छन्। परिवर्तन विन्डोमा यीमध्ये केही पनि वैकल्पिक छैन।

पूलभित्रको क्लाइन्ट र बाहिरको क्लाइन्टबाट परीक्षण गरेर टुङ्ग्याउनुहोस्। जुन नियम तपाईंले टाइप गरेको मेसिनबाट मात्र चल्छ, त्यो नीति होइन।