सर्व पोर्ट फॉरवर्ड करणारे नियम तुमचा WireGuard लिसनर गिळू शकतात

एक सार्वजनिक गेटवे आधीच 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.1

SNAT नियम भाषांतरित बॅकएंड आणि मूळ सार्वजनिक गंतव्याशी जुळतो, त्यामुळे त्याच बॅकएंड सेवेचे दुसरे जोडणी या नकाशाबाहेर राहते. तो अभ्यागताचा पत्ता पीअरपासून लपवतोही, आणि हाच तो तडजोड ज्यामुळे स्रोत जपणारा मार्गित परतीचा मार्ग वेगळी रचना बनतो. 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 व्यापणारा नियम ती प्रकरणे पूर्वनिर्धारित शृंखलेवर सोडतो.

नियम लिहिण्यापूर्वी मॉडेल निवडा

चार आकार गेटवेवरून होणाऱ्या बहुतेक प्रकाशनांना व्यापतात, आणि निवड तुम्ही किती सेवा चालवता आणि नियंत्रण तलात किती जोखीम सहन करू शकता यावर अवलंबून असते. खालील तक्ता त्यांना सर्वात अरुंद ते सर्वात रुंद अशा क्रमाने मांडतो.

पुढे अधिक सेवा अपेक्षित असल्या तरी अरुंद मॉडेलपासून सुरुवात करा. त्याचे लेखापरीक्षण सर्वात सोपे आहे, आणि अरुंद नियमांचा संच पुनरावलोकित सर्व पकडणाऱ्या नियमात बदलणे हे रुंद नियमाने कोणता लिसनर पकडला हे शोधण्यापेक्षा सोपे आहे. कोणतेही मॉडेल निवडा, नियम फायरवॉलच्या मालकाकडे ठेवा. त्याच शृंखला व्यवस्थापित करणाऱ्या UFW किंवा nftables संरचनेच्या शेजारी iptables ओळी लागू केल्यास बूट क्रमानुसार बदलणारे धोरण तयार होते.

प्रकाशन आणि नियंत्रण मार्ग दोन्ही सिद्ध करा

अधिकृत बाह्य क्लायंटवरून मंजूर होस्टनाव आणि त्यासाठी वैध प्रमाणपत्र वापरून चाचणी करा. कोणत्या बॅकएंडने उत्तर दिले ते निश्चित करा, नंतर असंबंधित सार्वजनिक पोर्ट नाकारले जात राहतात याची खात्री करा. अक्षम केलेली प्रमाणपत्र तपासणी उत्तीर्ण HTTPS चाचणी नाही, आणि चुकीच्या बॅकएंडपर्यंत पोहोचणारी जोडणी अयशस्वी जोडणीपेक्षा वाईट आहे.

त्यानंतर गेटवे स्वतः तपासा: एक WireGuard पीअर जोडा, एक SSH सत्र उघडा आणि देखरेख अजूनही अहवाल देत असल्याची खात्री करा. नियंत्रण तल बिघडलेले असतानाही प्रकाशित सेवा चालू शकते, म्हणून दोन्ही तपासण्या एकाच बदल खिडकीत येतात. नियम अपेक्षित क्रमाने पुन्हा लागू होतात हे सिद्ध करण्यासाठी एकदा रीबूट करा, नंतर प्रकाशन काढा आणि काढणे खरोखर जोडण्याशी जुळते याची खात्री करा. सुरुवातीला मोठ्या प्रमाणात जोडणे आणि अपूर्ण सफाई — तात्पुरती चाचणी कायमचे भोक बनण्याचा मार्ग हाच आहे.