VPN क्लायंट्सना टनेलवर एकमेकांपर्यंत पोहोचण्यापासून थांबवा

दोन क्लायंट दोघेही जंप होस्ट उघडू शकतात आणि तरीही एकमेकांना उघडण्याचे त्यांना काही काम नसावे। सेवेपर्यंत पोहोचणे हा फॉरवर्डिंगचा निर्णय आहे, तर पीअरपर्यंत पोहोचणे हा धोरणाचा निर्णय आहे, आणि बहुतेक VPN स्टॅक हे वेगळ्या ऑब्जेक्टमध्ये ठेवतात। पहिल्यासाठी तुम्ही कॉन्फिगर करता त्यातले काहीही दुसरे लागू करत नाही। त्यामुळे काम नियम जोडणे नाही, तर या सर्व्हरवर पीअर रहदारी ठरवणारा ऑब्जेक्ट शोधणे, तिथे निषेध लिहिणे आणि तो क्लायंटकडून सिद्ध करणे आहे।

सामायिक सेवेकडचा मार्ग पीअरमधील परवानगी नाही

क्लायंट सबनेटची जाहिरात पीअरला दुसऱ्या क्लायंटच्या पत्त्याकडे पॅकेट तारेवर कसे ठेवायचे ते सांगते। तो पॅकेट पोहोचेल की नाही हे नंतर त्याला फॉरवर्ड करणाऱ्याकडून ठरते। Linux गेटवेवर ती FORWARD शृंखला आहे; वापरकर्ता-जागेतील डेमॉनमध्ये ती टनेलची स्वतःची सत्र सारणी आहे। मार्ग पोहोचक्षमतेला उत्तर देतो आणि परवानगीला स्पर्श करत नाही।

म्हणून फक्त मार्ग वाचणारी अलगीकरण तपासणी काहीही सिद्ध करत नाही। /24 प्रत्येक क्लायंटला पाठवता येते, तर पीअरमधील प्रत्येक पॅकेट फॉरवर्ड हुकवर टाकले जाते। धोकादायक प्रसंग उलटा आहे: कोणताही स्पष्ट नियम नाही, परवानगी देणारे डीफॉल्ट आहे, आणि अलगीकरण फक्त यासाठी अस्तित्वात आहे की कोणीही त्याची चाचणी केली नाही।

टर्मिनल उघडण्यापूर्वी आवश्यकता एका ओळीत लिहा। सेवा ब्लॉक आणि जंप होस्टपर्यंत पोहोचा, क्लायंट ब्लॉकमध्ये दुसरे कुठेही पोहोचू नका।

पीअर पॅकेट प्रत्यक्षात कोण फॉरवर्ड करतो ते शोधा

सर्व्हरची दोन वर्तनं क्लायंटकडून सारखीच दिसतात आणि वेगळे नियम मागतात। एकतर कर्नेल पॅकेट पुन्हा टनेल इंटरफेसबाहेर फॉरवर्ड करते, किंवा डेमॉन ते सत्रांमध्ये कॉपी करतो आणि कर्नेल ते कधीही पाहत नाही।

WireGuard पहिल्या गटात आहे: त्यात पीअर-ते-पीअर स्विच नाही, त्यामुळे 10.8.0.4 ते 10.8.0.5 पॅकेट wg0 वर येते, फॉरवर्ड हुकला धडकते आणि AllowedIPs दोन्ही पत्ते व्यापतात तेव्हा पुन्हा wg0 मधून मार्गस्थ होते। OpenVPN दुसरा गट आहे, सर्व्हर कॉन्फिगमध्ये client-to-client सेट झाल्यावर, कारण ती सूचना पॅकेट वापरकर्ता जागेत सत्रांमध्ये सुपूर्द करते। काहीही लिहिण्यापूर्वी लोड झालेल्या कॉन्फिगमध्ये ती सूचना तपासा। रहदारी कधीही न पाहणारा कर्नेल नियम काम करणाऱ्या नियमापासून वेगळा करता येत नाही, आणि अशाच प्रकारे तैनाती कोणत्याही अलगीकरणाशिवाय संपते।

लोड झाले असे तुम्ही गृहीत धरता त्या फाइलऐवजी प्रभावी कॉन्फिग वाचा, कारण डिस्ट्रो पॅकेजेस स्वतःचे समावेश आणतात। डेमॉन फॉरवर्ड करत असेल, तर निषेध त्याच्या स्वतःच्या प्रति-क्लायंट नियंत्रणांमध्ये राहतो, आणि होस्ट फायरवॉल फक्त होस्टकडे पाठवलेली रहदारी गाळते। कर्नेल फॉरवर्ड करत असेल, तर फॉरवर्ड हुक हेच एकमेव महत्त्वाचे स्थान आहे।

मार्गित आणि भाषांतरित तैनातींना आणखी एक तपासणी लागते: दूरच्या क्लायंटला दिसणारा स्रोत तुम्ही अपेक्षित तो नसेल। तेव्हा क्लायंट सबनेटशी जुळणारा नियम कशाशीही जुळत नाही। जुळणी लिहिण्यापूर्वी भाषांतरातून टिकणारा पत्ता नोंदवा, आणि NAT पत्त्यांचा अंदाज लावण्यापेक्षा इंटरफेस जोडी जुळवण्यास प्राधान्य द्या।

प्रत्येक पत्त्याला स्वतंत्रपणे रद्द करता येणारी ओळख द्या

दोन उपकरणांनी एकच क्रेडेन्शियल वाटून घेतल्याबरोबर अलगीकरण कोसळते। त्या ओळखीशी बांधलेला नियम त्यांना वेगळे करू शकत नाही, आणि हरवलेला लॅपटॉप रद्द करणे संपूर्ण गट रद्द करते। प्रति-उपकरण प्रमाणपत्रे किंवा प्रति-पीअर किल्ल्या रद्दीकरण स्थानिक आणि धोरण वाचनीय ठेवतात, कारण प्रत्येक पत्ता नेमका एक व्यक्ती किंवा यंत्राशी जुळतो। जिथे रचना ते करू शकत नाही, तिथे नियमाला सूक्ष्म म्हणण्याऐवजी रनबुकमध्ये तसे सांगा।

पत्ता वाटप धोरणाशी सहमत असले पाहिजे। सेवांसाठी एक ब्लॉक, क्लायंटसाठी एक ब्लॉक राखून ठेवा, आणि क्लायंट पत्ते तुम्ही नियंत्रित करता त्या पूलमधून द्या, आधी येणारा आधी घेणारे श्रेणीतून नाही। सर्व्हर भाषांतर किंवा ब्रिज करत असेल, तर मॅपिंग सारणी कॉन्फिगजवळ ठेवा, कारण पुढच्या वाचकाला नियम पुन्हा काढण्यासाठी तीच सारणी लागते।

निषेध तिथे ठेवा जिथे पॅकेट टनेल ओलांडते

WireGuard रहदारी फॉरवर्ड करणाऱ्या गेटवेवर दोन नियम प्रसंग व्यापतात: सेवा ब्लॉकला परवानगी द्या, नंतर क्लायंट ब्लॉकचा उर्वरित भाग टाका। इंटरफेस जोडी पत्त्यांइतकीच महत्त्वाची आहे, कारण फक्त गंतव्यावर जुळवल्यास LANमधून येणारी रहदारीही पकडली जाते। परवानगी आधी मूल्यांकन व्हावी म्हणून ते त्याच क्रमाने लोड करा।

nftables सह जोडी विद्यमान inet filter सारणीत जाते, आधी परवानगी आणि नंतर टाकणे। दोन्ही जुळण्या पत्त्यांसह इंटरफेस जोडी पिन करतात।

nft add rule inet filter forward iifname "wg0" oifname "wg0" ip saddr 10.8.0.0/24 ip daddr 10.8.2.0/24 accept
nft add rule inet filter forward iifname "wg0" oifname "wg0" ip saddr 10.8.0.0/24 ip daddr 10.8.0.0/24 drop

लोड केल्यावर एक्झिट स्थितीवर विश्वास ठेवण्याऐवजी शृंखला परत वाचा, आणि दोन्ही नियम तुम्ही इच्छिलेल्या क्रमाने आहेत याची खात्री करा। IPv6 पूलसाठी जुळणारे ip6 नियम जोडा, अन्यथा दुहेरी स्टॅक टनेलवर v4 जोडी फक्त सजावट आहे। सर्व्हरकडे आधीच परवानगी देणारे फॉरवर्ड धोरण असेल, तर शृंखला पूर्णपणे बदलण्याऐवजी टाकणे जोडा।

OpenVPN वर client-to-client सक्षम असताना, हे फॉरवर्ड नियम पीअर रहदारीशी कधीही जुळत नाहीत आणि निषेध डेमॉनच्या स्वतःच्या नियंत्रणांमध्ये असला पाहिजे। होस्टकडे पाठवलेल्या रहदारीसाठी कर्नेल नियम ठेवा, पण त्यांना अलगीकरण नियंत्रण म्हणून मोजू नका।

निषेध सर्व्हरकडून नाही, क्लायंटकडून सिद्ध करा

गेटवेवरून तपासणी काहीही सिद्ध करत नाही, कारण स्थानिकरीत्या निर्माण झालेली रहदारी आउटपुट मार्ग घेते आणि फॉरवर्ड हुक कधीही ओलांडत नाही। दोन खरे क्लायंट वापरा: एक ज्याला सेवेपर्यंत पोहोचायचे आहे, एक ज्याला नाकारायचे आहे। आधी परवानगीचा प्रसंग चालवा, जेणेकरून तुटलेल्या टनेलचा काम करणारे धोरण असा गैरअर्थ लावला जाणार नाही।

परवानगी मिळालेल्या क्लायंटकडून सेवा तिच्या पोर्टवर उत्तर देते याची खात्री करा। त्याच क्लायंटकडून पीअरचा पत्ता वापरून पाहा आणि नकाराऐवजी शांत टाकण्याची अपेक्षा करा:

ping -c 3 -W 2 10.8.0.5
nc -z -w 2 10.8.0.5 22
nft list chain inet filter forward
iptables -vnL FORWARD
ping -6 -c 3 -W 2 fd00:8::5

टाकलेला पॅकेट आणि ऑफलाइन पीअर दोन्ही वेळ संपल्यासारखे दिसतात, त्यामुळे काही निष्कर्ष काढण्यापूर्वी काउंटर तपासा। पीअर स्पष्टपणे सुरू असताना टाकण्याच्या नियमाचा काउंटर वाढतो याची खात्री करा। IPv6 वर पुनरावृत्ती करा, जिथे अनुपस्थित ip6 नियम v4 निषेध प्रभावी दिसू देतो। स्वीकारलेले आणि नाकारलेले निकाल तारखेसह रनबुकमध्ये नोंदवा, कारण पुढील स्थलांतर नियम पुन्हा काढेल।