सबै पोर्ट फर्वार्ड गर्ने नियमहरूले तपाईंको WireGuard लिसनर निल्न सक्छन्
फराकिलो फर्वार्ड नियमले गेटवेका आफ्नै WireGuard र SSH लिसनर निल्न सक्छ। साँघुरा नियम वा छुट्टै सार्वजनिक ठेगाना छान्नुहोस्, त्यसपछि नियन्त्रण मार्ग परीक्षण गर्नुहोस्।
एउटा सार्वजनिक गेटवेले पहिले नै UDP 51820 मा WireGuard, 22 मा SSH र इन्टरनेटबाट पहुँचयोग्य हुनुपर्ने एउटा अनुप्रयोग चलाइरहेको छ। लोभ्याउने नियमले हरेक पोर्ट पीयरमा फर्वार्ड गर्छ र काम सकिएको घोषणा गर्छ। WireGuard गेटवेमा त्यो नियमले सुरुङको आफ्नै ट्रान्सपोर्ट समात्न सक्छ र त्यसलाई अन्त्य गर्ने मेसिनबाट तपाईंलाई बाहिर थुन्न सक्छ। प्रकाशन नियन्त्रण तलको अपवादसहितको राउटिङ निर्णय हो, एउटा DNAT लाइन होइन।
सार्वजनिक प्रवेश वा सुरुङ प्रवेश: एउटा छान्नुहोस्
सेवा प्रकाशित गर्दा इन्टरनेटमा नयाँ प्रवेश बिन्दु बन्छ। यो पीयरलाई VPN सदस्यता दिनु जस्तै होइन, किनकि आगन्तुक कहिल्यै सुरुङमा पस्दैन र गेटवे ब्याकइन्डको सार्वजनिक अनुहार बन्छ। त्यो भिन्नताले नियमको दर्शक र यसको प्रमाणपत्र तय गर्छ।
प्रशासनिक इन्टरफेसहरू त्यो स्थानमा विरलै पर्छन्। अधिकृत VPN क्लाइन्टले पुग्ने प्रशासन पृष्ठले आक्रमण सतह सुरुङभित्र राख्छ र लगइन फारमलाई मनपरी स्क्यानिङमा खुला गर्नबाट बच्छ। सार्वजनिक अनुप्रयोग अन्त्य बिन्दुहरूलाई अझै आफ्नै TLS प्रमाणपत्र, प्रमाणीकरण र दर सीमा चाहिन्छ; इन्क्रिप्टेड WireGuard हपले आगन्तुकको गेटवेसम्मको भाग जोगाउँदैन।
यदि सेवा साँच्चै सार्वजनिक हुनैपर्छ भने होस्टनाम, त्यसलाई समेट्ने प्रमाणपत्र र त्यहाँ पुग्नुपर्ने आगन्तुक दायराहरू लेख्नुहोस्। ती तीन तथ्यले पछि नियमको आकार र फिल्टर नीति तय गर्छन्। तिनीबाहिरको सबै सार्वजनिक लिसनरमा दायरा विस्तार हो।
एउटा पोर्ट भित्र, एउटा ब्याकइन्ड बाहिर
एउटै सार्वजनिक पोर्ट र एउटै ब्याकइन्ड सेवा प्रयोग गर्नुहोस्। यो उदाहरणमा eth0 ले सार्वजनिक ठेगाना 198.51.100.20 बोक्छ, गेटवेको सुरुङ ठेगाना 10.200.0.1 हो, र पीयरले अनुप्रयोग 10.200.0.7 मा चलाउँछ। सार्वजनिक TCP 9443 पीयरको TCP 8443 मा म्याप हुन्छ:
iptables -t nat -A PREROUTING -i eth0 -d 198.51.100.20 -p tcp --dport 9443 -j DNAT --to-destination 10.200.0.7:8443
iptables -t nat -A POSTROUTING -o wg0 -d 10.200.0.7 -p tcp --dport 8443 -m conntrack --ctorigdst 198.51.100.20 --ctorigdstport 9443 -j SNAT --to-source 10.200.0.1SNAT नियम अनुवादित ब्याकइन्ड र मूल सार्वजनिक गन्तव्यसँग मेल खान्छ, त्यसैले उही ब्याकइन्ड सेवामा अर्को जडान यो म्यापिङबाहिर रहन्छ। यसले आगन्तुकको ठेगाना पीयरबाट लुकाउँछ पनि, र त्यही सम्झौता हो जसले स्रोत जोगाउने राउटेड फिर्तीलाई छुट्टै डिजाइन बनाउँछ। iptables एक्सटेन्सन सन्दर्भ ले दुवै लक्ष्य र तिनका मिलान विकल्पहरूको वर्णन गर्छ।
फर्वार्डिङ अझै सक्षम हुनुपर्छ, र फिल्टर चेनलाई अनुवादित गन्तव्य र पोर्ट तथा स्थापित जवाफहरूका लागि अनुमति चाहिन्छ। FORWARD चेनले DNAT पछिको अनुवादित गन्तव्य देख्छ, त्यसैले सार्वजनिक ठेगानामा लेखिएको नियम फर्वार्ड हुने प्याकेटसँग मेल खाँदैन। अनुमति सार्वजनिकमा होइन, ब्याकइन्ड टपलमा लेख्नुहोस्।
पीयरले गेटवेको सुरुङ ठेगानाबाट सेवा जडान स्वीकार गर्नुपर्छ र जवाफ सुरुङबाट फर्काउनुपर्छ। यसको AllowedIPs ले वास्तवमै प्राप्त हुने स्रोतलाई अधिकृत गर्नुपर्छ, जुन स्रोत अनुवादमा गेटवेको सुरुङ ठेगाना हो, र यो डिजाइनका लागि हरेक पीयरमा फराकिलो 0.0.0.0/0 प्रविष्टि आवश्यक छैन। फिर्ती ट्राफिक खसाल्ने कुरा त्यो ठेगाना सूचीबाट छुटेको पीयर हो, वा त्यसको सट्टा आगन्तुकको आफ्नै ठेगाना फर्वार्ड गर्ने स्रोत जोगाउने डिजाइन हो, त्यसैले तपाईंको नियमको होइन, पीयरले साँच्चै देख्ने स्रोत जाँच्नुहोस्।
गेटवेका आफ्नै लिसनर नियमबाहिर राख्नुहोस्
पोर्ट मिलानलाई हरेक TCP र UDP गन्तव्य समेट्ने नियमले बदल्नुहोस्, र गेटवेको आफ्नै WireGuard सकेट त्यभित्र पर्छ। गन्तव्य अनुवाद मेसिनले प्याकेट स्थानीय हो भनी निर्णय गर्नुअघि हुन्छ, त्यसैले UDP 51820 हरेक पीयर जडान राख्ने प्रक्रियाको सट्टा पीयरमा पुग्न सक्छ। नियम सफलतापूर्वक लोड हुन्छ र सुरुङ मर्छ, जुन पीयरको तर्फबाट पढ्न गाह्रो विफलता हो।
SSH, अनुगमन एजेन्ट र गेटवेमा होस्ट गरिएका अन्य सेवाहरूको पनि त्यही जोखिम हुन्छ। सबै फर्वार्ड गर्ने नियमले नियन्त्रण तललाई प्रकाशित अनुप्रयोगबाट छुट्याउँदैन, र परिवर्तनपछिको पहिलो रिबुट त्यो क्षण हो जब थुनिएको कुरा स्पष्ट हुन्छ। सबै समात्ने नियमले चुपचाप आफ्नो बनाएको सेवाबारे चेतावनी दिँदैन। अर्को जडान विफल हुँदा तपाईंले थाहा पाउनुहुन्छ।
यदि फराकिलो फर्वार्डिङ साँच्चै आवश्यक छ भने सबै समात्ने नियमअघि नियन्त्रण पोर्ट आरक्षित गर्नुहोस् वा प्रकाशनका लागि छुट्टै सार्वजनिक ठेगाना प्रयोग गर्नुहोस्। दोस्रो विकल्प सफा छ किनकि नियन्त्रण ठेगानाले आफ्नै नीति राख्छ, तर प्रदायकले त्यो ठेगाना दिनुपर्छ; DNS रेकर्ड थप्दा ठेगाना आवंटन हुँदैन।
फराकिलो TCP र UDP फर्वार्डिङ पनि सबै प्रोटोकल होइन। ICMP, IPv6, path-MTU प्रतिक्रिया र बाहिरी VPN ट्रान्सपोर्टलाई आफ्नै नीति चाहिन्छ, र TCP तथा UDP समेट्ने नियमले ती केसहरू पूर्वनिर्धारित चेनमा छोड्छ।
नियम लेख्नुअघि मोडेल छान्नुहोस्
चार आकारले गेटवेबाट हुने अधिकांश प्रकाशन समेट्छन्, र छनोट तपाईंले कति सेवा चलाउनुहुन्छ र नियन्त्रण तलमा कति जोखिम सहन सक्नुहुन्छ भन्नेमा निर्भर गर्छ। तलको तालिकाले तिनलाई सबैभन्दा साँघुरोदेखि सबैभन्दा फराकिलोसम्म क्रमबद्ध गर्छ।
| Model | What it protects | Cost | Use when |
|---|---|---|---|
| Narrow port forward | Every other listener, including the VPN | One rule per service | Few services, stable ports |
| Catch-all with reserved ports | Ports named in the exception list | Rule order becomes critical | Many services and disciplined review |
| Separate public address | Control address fully isolated | Provider must supply the address | High-value publication |
| VPN-only access | No public entry at all | Visitors need the tunnel | Admin interfaces and internal tools |
पछि थप सेवा अपेक्षा गरे पनि साँघुरो मोडेलबाट सुरु गर्नुहोस्। यसको अडिट गर्न सबैभन्दा सजिलो छ, र साँघुरा नियमहरूको समूहलाई समीक्षा गरिएको सबै समात्ने नियममा बदल्नु फराकिलो नियमले कुन लिसनर समात्यो भनी पत्ता लगाउनुभन्दा सरल छ। जुनसुकै मोडेल छान्नुहोस्, नियमहरू फायरवालको मालिकसँग राख्नुहोस्। उही चेनहरू व्यवस्थापन गर्ने UFW वा nftables कन्फिगरेसनको छेउमा iptables लाइनहरू लागू गर्दा बुट क्रमअनुसार बदलिने नीति बन्छ।
प्रकाशन र नियन्त्रण मार्ग दुवै प्रमाणित गर्नुहोस्
अधिकृत बाह्य क्लाइन्टबाट स्वीकृत होस्टनाम र त्यसका लागि मान्य प्रमाणपत्र प्रयोग गरी परीक्षण गर्नुहोस्। कुन ब्याकइन्डले जवाफ दियो भनी पुष्टि गर्नुहोस्, त्यसपछि असम्बन्धित सार्वजनिक पोर्टहरू अस्वीकृत रहेको जाँच्नुहोस्। अक्षम गरिएको प्रमाणपत्र जाँच उत्तीर्ण HTTPS परीक्षण होइन, र गलत ब्याकइन्डमा पुग्ने जडान असफल जडानभन्दा नराम्रो हो।
त्यसपछि गेटवे आफै जाँच्नुहोस्: एउटा WireGuard पीयर जोड्नुहोस्, एउटा SSH सत्र खोल्नुहोस् र अनुगमनले अझै रिपोर्ट गरेको पुष्टि गर्नुहोस्। नियन्त्रण तल बिग्रिएको अवस्थामा पनि प्रकाशित सेवा चल्न सक्छ, त्यसैले दुवै जाँच एउटै परिवर्तन विन्डोमा पर्छन्। नियमहरू अपेक्षित क्रममा फेरि लागू हुने प्रमाणित गर्न एक पटक रिबुट गर्नुहोस्, त्यसपछि प्रकाशन हटाउनुहोस् र हटाउने काम थप्नेसँग साँच्चै मेल खान्छ भनी पुष्टि गर्नुहोस्। सुरुमा ठूलो संख्यामा थप र अपूर्ण सफाइ — अस्थायी परीक्षण स्थायी प्वाल बन्ने तरिका यही हो।