VPN के बाहर सिर्फ़ एक स्थानीय वेब सेवा को पोर्ट के हिसाब से रूट करें

एक होस्ट सेवा को भौतिक अपलिंक से इंटरनेट का जवाब देना है, जबकि मशीन पर बाकी सब कुछ सुरंग का उपयोग करता रहे। नीति-आधारित रूटिंग यह भार उठा सकती है या नहीं, यह तीन शर्तें तय करती हैं, और नियम लिखने से पहले हर एक की जाँच सस्ती है। सेवा को DNAT या फ़ॉरवर्ड किए गए पोर्ट के पीछे नहीं, इसी होस्ट पर समाप्त होना चाहिए, VPN के अपने नियमों को यह अपवाद अनुमत करना चाहिए, और आपको अनुरोध नहीं, जवाब का मिलान करना है। तीनों में से कोई भी विफल हो तो नीचे दिए गए आदेश बिना त्रुटि लोड होंगे, पर कुछ भी उपयोगी नहीं करेंगे।

नियम लिखने से पहले तीनों शर्तें जाँचें

DNAT के ज़रिये पोर्ट प्रकाशित करने वाला कंटेनर, या पोर्ट फ़ॉरवर्डिंग के पीछे बैठा सर्वर, ऐसे पैकेट बनाता है जो इस होस्ट पर पैदा नहीं होते। वे पैकेट फ़ॉरवर्ड किए जाते हैं, इसलिए होस्ट-स्थानीय इनपुट पर आधारित नियम उन्हें कभी नहीं देखता और ट्रैफ़िक डिफ़ॉल्ट रूट लेता रहता है। आगे बढ़ने से पहले पुष्टि करें कि सेवा वास्तव में कहाँ चलती है, क्योंकि लोग इसी शर्त में सबसे ज़्यादा गलती करते हैं।

दूसरी शर्त नीति है, यांत्रिकी नहीं। सुरंग को बाईपास करने वाला हर रूट सुरंग के उद्देश्य का अपवाद है, और प्रबंधित होस्ट पर यह निर्णय नीति के मालिक का है, टाइमआउट डीबग करने वाले व्यक्ति का नहीं।

जवाब का मिलान करें, क्लाइंट के गंतव्य पोर्ट का नहीं

TCP 443 पर सुनने वाले सर्वर का जवाब होस्ट से स्रोत पोर्ट 443 के साथ निकलता है। उसी होस्ट का ब्राउज़र किसी दूरस्थ HTTPS साइट से जुड़ते समय क्षणिक स्रोत पोर्ट और गंतव्य पोर्ट 443 भेजता है। दोनों पोर्ट 443 का ट्रैफ़िक हैं और इनमें से सिर्फ़ एक को WAN तालिका लेनी चाहिए, इसीलिए गंतव्य-पोर्ट मिलान गलत आधा हिस्सा पकड़ लेता।

जवाब की दिशा ही वह चीज़ है जिसे आप अलग कर सकते हैं। स्रोत पोर्ट का मिलान करें, नियम को स्थानीय रूप से बनाए गए पैकेट तक सीमित रखें, और नियम ब्राउज़र के अनुरोधों को छुए बिना सेवा के अपने जवाबों को कवर कर लेता है।

नियम के उसकी ओर इशारा करने से पहले पूरी रिटर्न तालिका बनाएँ

खाली तालिका का अर्थ है कोई रूट नहीं, जो टूटी नीति से ज़्यादा टूटी सेवा जैसा दिखता है। पहले उसे भरें, ऐसी तालिका संख्या और प्राथमिकता से जिस पर होस्ट पर और कुछ दावा न करे:

ip -4 route add table 100 192.0.2.0/24 dev eth0
ip -4 route add table 100 default via 192.0.2.1 dev eth0
ip -4 rule add priority 1000 iif lo ipproto tcp sport 443 lookup 100

संख्याएँ नकल करने के बजाय जीवंत होस्ट से पढ़ें। ip -4 rule show बताता है कि कौन-सी प्राथमिकताएँ ली जा चुकी हैं, और पहले से मौजूद प्राथमिकता पर नियम जोड़ने से अलग-अलग ठीक दिखने वाले दो नियमों का क्रम चुपचाप बदल जाता है।

यहाँ असली काम दो चयनकर्ता करते हैं। iif lo यह बताता है कि कर्नेल उन पैकेट की सूचना कैसे देता है जो होस्ट ने खुद बनाए, इसलिए नियम बाहर से आने वाले फ़ॉरवर्ड ट्रैफ़िक को गलती से नहीं पकड़ सकता। ipproto tcp sport 443 इसे एक ट्रांसपोर्ट और एक पोर्ट तक सीमित करता है, जो आवश्यकता के अनुसार जितना तंग हो सकता है उतना तंग है। प्रोटोकॉल चयनकर्ता हटा दें तो नियम UDP 443 भी पकड़ लेगा, जो अलग व्यवहार वाली अलग सेवा है।

निजी जवाब सुरंग के अंदर रखें

अगर वही लिसनर निजी पक्ष के क्लाइंट को भी जवाब देता है, तो तालिका 100 में सब कुछ पकड़ने वाला WAN डिफ़ॉल्ट उन जवाबों को अपलिंक से वापस भेजने की कोशिश करेगा। जो निजी प्रीफ़िक्स WAN डिफ़ॉल्ट का पालन नहीं करने चाहिए उन्हें जोड़ें, या उन्हें अगले नीति-नियम पर गिरने दें:

ip -4 route add table 100 throw 10.90.0.0/24

throw रूट इस तालिका में खोज समाप्त करता है और पैकेट को नियमों की सूची को लौटा देता है, ताकि उसके बाद आने वाली VPN नीति को अपना मौका मिले। यह खुद सुरंग में कुछ भी रूट नहीं करता, और अगर किसी बाद के नियम के पास मेल खाता रूट नहीं है तो पैकेट फिर भी विफल होता है; throw को समाधान मानने के बजाय अगली नीति जाँचें।

रिवर्स-पाथ फ़िल्टरिंग और होस्ट फ़ायरवॉल नियम आने वाले अनुरोध पर अब भी लागू होते हैं। सत्यापन ढीला करने से पहले उनके असली फ़ैसले देखें, क्योंकि रूटिंग अपवाद rp_filter को असंभव माने जाने वाले वापसी पथ को स्वीकार करने पर मजबूर नहीं करता।

TCP, फिर QUIC, फिर रीबूट जाँचें

अधिकृत बाहरी क्लाइंट से एक और निजी पक्ष से एक कनेक्शन खोलें, फिर असली पतों और पोर्ट के साथ जवाब-खोज जाँचें। बाहरी जवाब तालिका 100 ले और निजी जवाब न ले, तो नीति वही कर रही है जो आपने माँगा।

HTTP/3 UDP पर परोसा जाता है और TCP नियम से मेल नहीं खाएगा, इसलिए QUIC लिसनर को अपना चयनकर्ता चाहिए, वरना HTTPS चलते रहने पर भी वह सुरंग का उपयोग करता रहेगा। जिन नियमों पर आप टिकते हैं उन्हें इंटरफ़ेस का मालिक घटक से सहेजें, और फिर से जुड़ने या DHCP नवीनीकरण के बाद उनकी पुष्टि करें। रीबूट के बाद कोई प्रतिस्पर्धी मैनेजर रनटाइम रूट हटा दे, तो वह मूल में ठीक करने वाली स्वामित्व समस्या है, ऊपर और विस्तृत NAT नियम जोड़ने का कारण नहीं।