VPN आणि वेबसाठी एकच सार्वजनिक होस्ट: भूमिका कशा विभागायच्या

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

पुढे जे आहे ते निर्णय प्रक्रिया आहे, बांधकाम पत्रक नाही. प्रत्येक पायरी आत्ता जोडलेली भूमिका खरोखर वेगळी आहे हे सिद्ध करणाऱ्या तपासणीने संपते.

पोर्टपेक्षा आधी पत्त्याचा मालक निवडा

टनलचा शेवटचा बिंदू आणि वेब सर्व्हर एकच कर्नेल सामायिक करू शकतात; एकाच वेळी एक पत्ता, पोर्ट आणि प्रोटोकॉल सामायिक करणे हेच अयशस्वी होते. WireGuard सहसा UDP 51820 घेतो, OpenVPN UDP 1194 किंवा TCP 443 घेतो, आणि वेब सर्व्हर TCP 443 घेतो. दुखावणारी जोडी म्हणजे HTTPS च्या शेजारी TCP 443 वरचा OpenVPN, कारण दोन्हीना एकच सॉकेट हवे असते आणि कर्नेल ते आधी बाइंड करणाऱ्याला देतो. फक्त समोरचा डिमल्टिप्लेक्सर, जसे sslh किंवा TLS समजणारा प्रॉक्सी, त्यांना तो पोर्ट सामायिक करू देतो, आणि तो असा घटक जोडतो ज्याचा बिघाड फायरवॉल समस्येसारखाच दिसतो.

काहीही बदलण्यापूर्वी मालकांकडे पहा: ss -lntup ऐकणाऱ्या प्रत्येक सॉकेटचा स्थानिक पत्ता, पोर्ट आणि प्रक्रिया छापतो. दाखवणाऱ्या दोन ओळी 0.0.0.0:443 म्हणजे दुसरी सेवा कधीच बाइंड झाली नाही, तिची init स्क्रिप्ट कितीही आनंदी असो. ब्रिजिंग मालकही हलवते. जेव्हा eth0 खालील ब्रिजला जोडले जाते: br0, IP br0 वर जातो आणि eth0 असे नाव घेणारा प्रत्येक फायरवॉल नियम जुळणे थांबवतो, म्हणून सेवा ब्रिजवर बाइंड करा आणि ip -br addr ने पुष्टी करा.

तेच मालकीचे नियम व्हर्च्युअल मशीन्सबरोबर येणारे आश्चर्य स्पष्ट करते. त्याच LAN वरील गेस्टच्या आत चालणारा टनल सर्व्हर गेस्टचा पत्ता ठेवतो, म्हणून होस्टच्या स्वतःच्या पत्त्याकडे निर्देशित कनेक्शन होस्टवरच राहतात आणि गेस्टची टनल ती कधीच पाहत नाही, क्लायंट प्रोफाइल काहीही सांगो.

दोन LAN मध्ये राउट करा किंवा एक बाजू NAT करा

एकमेकांना न दिसणाऱ्या दोन LAN प्रत्येकी सार्वजनिक होस्टला कॉल करू शकतात, जो नंतर टनलमध्ये फॉरवर्ड करतो. या राउटेड रचनेला तीन गोष्टी हव्यात: फॉरवर्डिंग सुरू, प्रत्येक दूरच्या प्रीफिक्सकडे रूट आणि ट्रान्झिट जाऊ देणारे फॉरवर्डिंग धोरण. sysctl -w net.ipv4.ip_forward=1 पहिली गोष्ट समाविष्ट करते, ip route add 10.20.0.0/24 dev wg1 दुसरी, आणि nftables ची ओळ जसे nft add rule inet filter forward iifname "wg0" oifname "wg1" accept तिसरी.

स्रोत NAT जोडणे सोपे आणि डीबग करणे कठीण. मास्करेडिंग क्लायंटचा पत्ता पुन्हा लिहिते, म्हणून दूरची बाजू खऱ्या होस्टऐवजी हब पाहते, आणि तिचे प्रवेश नियम व लॉग श्रेयासाठी निरुपयोगी होतात. दोन्ही नेटवर्क तुमची असतील तर राउट करा. एक बाजू तिसऱ्या पक्षाची असेल आणि तो परतीचा रूट जोडणार नसेल तर NAT हा या आठवड्यात बाहेर पडणारा पर्याय आहे. कोणत्याही परिस्थितीत पत्ता योजना लिहून ठेवा, कारण दोन ओव्हरलॅपिंग /24 कोणत्याही कॉन्फिगरेशनने राउट करता येत नाहीत.

लॅपटॉपसाठी इंटरनेट एक्झिट म्हणून काम करणे यामुळे त्याच बॉक्सला येणाऱ्या टनल संपवण्यापासून काहीच प्रतिबंध होत नाही. फक्त ओव्हरलॅपिंग पत्तेच प्रतिबंध करतात, आणि म्हणूनच पत्ता योजना हा महत्त्वाचा दस्तऐवज आहे.

दोन भूमिका थांबलेल्या असताना विभाजन तपासा

उपयुक्त चाचणी वजाबाकी आहे: दोन भूमिका थांबवा आणि तिसरी अजूनही उत्तर देते याची खात्री करा. टनल सेवा बंद असताना वेब विनंती पूर्ण व्हायला हवी, आणि वेब सर्व्हर थांबलेला असताना टनल हातमिळवणी पूर्ण व्हायला हवी. दोन्ही सर्व काही चालत असेल तेव्हाच काम करत असतील तर तुमच्याकडे अपघाती अवलंबित्व आहे, जसे सामायिक फायरवॉल तक्ता, भरकटलेला रूट किंवा चुकीच्या पत्त्याकडे दाखवणारे नाव.

तीन कमांड ती चाचणी ठोस करतात. curl -sk --resolve example.test:443:203.0.113.10 https://example.test/ बाह्य DNS शिवाय स्थानिक श्रोता उत्तर देतो हे सिद्ध करते, wg show क्लायंटवर हातमिळवणी पूर्ण झाली हे सिद्ध करते, आणि tcpdump -ni any port 51820 हबवर राउटिंग समस्या की समस्येपासून वेगळी करते. कॅप्चरमध्ये कधीच न दिसणारी हातमिळवणी होस्टपूर्वी मेली: प्रदात्याचा फायरवॉल, चुकीचा सार्वजनिक पत्ता किंवा वाटेत NAT नियम.

फॉरवर्ड होणाऱ्या LAN साठी वजाबाकी पुन्हा करा. एक सहकारी डिस्कनेक्ट असताना हबमार्गे पिंग अयशस्वी व्हायला हवा; पुन्हा जोडल्यावर कोणत्याही नियमाला स्पर्श न करता पिंग परत यायला हवा. टनल पुन्हा सुरू केल्यावरच परत येणारा पिंग पोहोचक्षमतेकडे नाही, धोरणाकडे निर्देश करतो, आणि ते वेगळे दुरुस्ती आहे.

भूमिका वजा करताना नियमसंच वाचनीय ठेवा. nft list ruleset प्रत्यक्षात हव्या असलेल्या प्रत्येक दिशेसाठी एक स्वीकृती नियम दाखवावा, आणि सर्व काही स्वीकारणारी फॉरवर्ड साखळी विभाजन नाही, ती चालणारी डेमो आहे.

फक्त IPv6 प्रवेश रेषा आणि IPv4 सेवा

काही प्रवेश रेषा फक्त IPv6 पोहोचक्षमता देतात, आणि सेवा तरीही IPv4 वर प्रकाशित कराव्या लागतात. टनल स्वतः अजूनही रहदारी पास करणाऱ्या कुटुंबातून जाते, तर प्रकाशित सेवा टनलच्या आतल्या पत्त्यावर बसते. हे नेहमीच्या गृहीतकाला उलटते आणि देखरेख शांतपणे तोडते: IPv4 मार्गासाठी लिहिलेला फायरवॉल नियम किंवा अपटाइम तपासणी आता काहीही वाहून नेणाऱ्या इंटरफेसवर लक्ष ठेवते.

प्रत्येक कुटुंब स्वतंत्रपणे तपासा curl -4 आणि curl -6 ने, कारण एक यशस्वी विनंती तुम्ही न तपासलेल्या मार्गाबद्दल काहीच सांगत नाही. पोर्टची मालकी कुटुंबांमध्ये बदलत नाही, पण श्रोता बदलतो: ss -lntup IPv4 आणि IPv6 सॉकेट स्वतंत्र ओळींमध्ये सूचीबद्ध करते, आणि 0.0.0.0:443 व्यापत नाही [::]:443 ला, जोपर्यंत प्रक्रियेने dual-stack सॉकेट मागितले नाही.

एका कुटुंबावर उत्तर देणारी आणि दुसऱ्यावर नकार देणारी सेवा सहसा श्रोत्याची समस्या असते, राउटिंगची नाही. रचना पूर्ण म्हणण्यापूर्वी प्रत्येक भूमिकेकडे स्वतःचा पत्ता किंवा पोर्ट आहे, फॉरवर्डिंग सुरू व अनुमत आहे, आणि इतर दोन थांबलेले असतानाही प्रत्येक भूमिका उत्तर देते याची खात्री करा.