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 जब तक प्रक्रिया ने ड्यूअल-स्टैक सॉकेट न माँगा हो।

जो सेवा एक परिवार पर जवाब देती है और दूसरे पर मना कर देती है, वह आमतौर पर श्रोता की समस्या है, रूटिंग की नहीं। डिज़ाइन को पूरा कहने से पहले पुष्टि करें कि हर भूमिका का अपना पता या पोर्ट है, फ़ॉरवर्डिंग चालू और अनुमत है, और बाकी दो बंद होने पर भी हर भूमिका जवाब देती है।