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