पोर्ट 80 और 443 के नियम ब्राउज़र को VPN से नहीं भेजते
पोर्ट मिलान TCP प्रवाह चुनता है, ब्राउज़र नहीं। HTTP/3 UDP पर चलता है, DNS दूसरा रास्ता ले सकता है, और अपडेटर उसी नियम से मेल खाता है जो आपने लिखा।
कोई कहता है कि ब्राउज़र टनल का उपयोग करे, और जवाब गंतव्य पोर्ट 80 और 443 से मेल खाते फ़ायरवॉल नियम के रूप में आता है। यह सटीक दिखता है और है नहीं। पोर्ट मिलान पैकेट को उनके परिवहन हेडर से चुनता है, इससे नहीं कि किस प्रोग्राम ने सॉकेट खोला, और आधुनिक ब्राउज़िंग TCP पर उन दो पोर्ट तक सीमित नहीं है। नियम उस ट्रैफ़िक को छोड़ देगा जिसे आप शामिल करना चाहते थे और उस ट्रैफ़िक को पकड़ लेगा जिसे आपने कभी छूने की सोची नहीं। इसे लिखने से पहले तय करें कि तीन अलग सीमाओं में से आपको वास्तव में कौन-सी चाहिए।
नियम परिवहन वर्ग का वर्णन करता है, किसी एप्लिकेशन का नहीं
Linux में, गंतव्य-पोर्ट मिलान TCP हेडर की जाँच करता है और उसके ऊपर कुछ नहीं। उन पैकेटों को चिह्नित करना और नीति-मार्ग से भेजना ठीक वैसे ही काम करता है जैसे दस्तावेज़ित है, और इनमें से कोई भी तंत्र नहीं जानता कि पेलोड का क्या अर्थ है या किस प्रक्रिया ने इसे भेजा। चिह्न पैकेट से जुड़ी एक संख्या है, एप्लिकेशन से जुड़ी पहचान नहीं।
nft add rule inet mangle output tcp dport { 80, 443 } meta mark set 0x1
ip rule add fwmark 0x1 table 100
ip route add default dev wg0 table 100तुरंत दो परिणाम आते हैं। TCP 443 से संपर्क करने वाला सॉफ़्टवेयर अपडेटर ब्राउज़र जैसा ही व्यवहार पाता है, जो ठीक हो सकता है या अगली अपडेट चक्र की प्रतीक्षा करता व्यवधान हो सकता है। और जानबूझकर किसी दूसरे पोर्ट पर, मान लीजिए 8443, प्रकाशित वेब सेवा पूरी तरह नियम से बाहर रह जाती है, जबकि वह अब भी वही वेब ट्रैफ़िक है जिसकी उपयोगकर्ता को चिंता थी।
संख्याएँ वैध चयनकर्ता हैं जब आवश्यकता वास्तव में उन पोर्टों की हो। वे कल्पना बन जाती हैं जब टिकट में «ब्राउज़र» लिखा हो और नियम-समुच्चय में पोर्ट-श्रेणी लागू की जाए। यह अंतर दस्तावेज़ीकरण की बारीकी नहीं है। यह उस नियम के बीच का फ़र्क़ है जिसे आप समीक्षा में उचित ठहरा सकते हैं और उसके बीच जिसे कोई जाँच नहीं सकता।
HTTP/3 चुपचाप आपके TCP नियम को छोड़ देता है
HTTP/3 QUIC पर चलता है, और QUIC UDP में ढोया जाता है। केवल TCP से मेल खाने वाला नियम इसे देख नहीं सकता, इसलिए जो ब्राउज़र आपके परीक्षण पृष्ठ को पूरा करता है वही बाद का अनुरोध UDP पर भेजकर टनल से बच सकता है, बिना किसी के कोई सेटिंग बदले। RFC 9114 HTTP/3 को QUIC-आधारित प्रोटोकॉल बताता है, और सामान्य परिनियोजन में QUIC UDP का उपयोग करता है जिसका डिफ़ॉल्ट पोर्ट 443 है।
कोई दिया हुआ ब्राउज़र HTTP/3 आज़माएगा या नहीं, यह उसके कॉन्फ़िगरेशन, साइट और इस पर निर्भर है कि पिछला प्रयास सफल हुआ या नहीं। इससे इस पर स्मृति से तर्क करना कठिन हो जाता है। इसके बजाय उपकरण से पूछें:
curl --http3 -sS -o /dev/null -w '%{http_version} %{time_total}\n' https://example.com
ss -tunp | grep -E ':443\b'curl पंक्ति बातचीत किया गया संस्करण छापती है, इसलिए 3 पुष्टि करता है कि UDP मार्ग इस्तेमाल हुआ। फिर सॉकेट सूची दिखाती है कि वह कनेक्शन टनल इंटरफ़ेस से बँधा है या भौतिक से। यदि आपके curl बिल्ड में HTTP/3 नहीं है, तो फ़्लैग चुपचाप पीछे हटने के बजाय ज़ोर से विफल होता है, जो उसकी अपनी छोटी दया है।
DNS एक अलग निर्णय है जो आपको लेना है
वेब ट्रैफ़िक के लिए पोर्ट नियम नाम-समाधान के बारे में कुछ नहीं कहता। ब्राउज़र सिस्टम रिज़ॉल्वर, ब्राउज़र के भीतर कॉन्फ़िगर किया गया रिज़ॉल्वर, या वह उपयोग कर सकता है जिसे अंतिम कनेक्शन ने धकेला हो। इनमें से हर एक प्रश्नों को उस मार्ग से अलग भेज सकता है जो आपका नियम चुनता है, जिससे वही पुरानी दरार बनती है: पृष्ठ लोड होता है, नाम कहीं ऐसी जगह हल होता है जहाँ आपने सोचा नहीं था, और आंतरिक साइट सार्वजनिक पते पर हल होती है या बिल्कुल नहीं।
इसे स्पष्ट रूप से तय करें। यदि आंतरिक नाम टनल से हल होने चाहिए, तो रिज़ॉल्वर उसके भीतर होना चाहिए, और नियम-समुच्चय को उस रिज़ॉल्वर तक DNS की अनुमति देनी चाहिए और अन्य प्रश्नों को बाहर रखना चाहिए। यदि ब्राउज़र किसी सार्वजनिक प्रदाता के लिए DNS over HTTPS का उपयोग करता है, तो प्रश्न आपके रिज़ॉल्वर को पूरी तरह बायपास करता है और पोर्ट नियम मदद नहीं कर सकता। चुनाव को उसी परिवर्तन-रिकॉर्ड में लिखें जिसमें राउटिंग नियम है, क्योंकि अगली विफलता को डीबग करने वाला दोनों को साथ पढ़ता है।
फिर पृष्ठ से नहीं, रिज़ॉल्वर से सत्यापित करें:
resolvectl query intranet.example.internal
resolvectl status | grep -A3 'Current DNS Server'उत्तर न मिलना समाधान की समस्या है, तब भी जब ब्राउज़र का त्रुटि संदेश नेटवर्क को दोष देता है। ये दो विफलताएँ उपयोगकर्ता को एक जैसी दिखती हैं और पूरी तरह अलग टिकट हैं।
तीन सीमाएँ, तीन अलग तंत्र
अधिकांश भ्रम तब मिट जाता है जब आप उस सीमा का नाम लेते हैं जो आपको चाहिए। ये एक-दूसरे की जगह नहीं ले सकतीं, और टनल टूटने पर हर एक का विफलता का तरीका अलग है।
| What you actually want | Mechanism that fits | What it does not cover |
|---|---|---|
| These transport ports use this exit | Firewall mark plus policy route | Applications, HTTP/3 over UDP, DNS |
| This browsing session stays separate | Application-aware VPN, or a separate network namespace plus a proxy | Other applications in the same session |
| Only these private sites are reachable | Destination-based routes with private DNS | Public sites on the same address family |
अलग ब्राउज़र प्रोफ़ाइल मध्य पंक्ति का जाल है। यह कुकीज़ और इतिहास अलग करता है, और होस्ट की राउटिंग तालिका में कुछ नहीं बदलता, इसलिए दोनों प्रोफ़ाइल एक ही रास्ता लेते हैं। अलगाव के लिए कुछ ऐसा चाहिए जो कर्नेल लागू करे, यानी नेमस्पेस, कंटेनर या ऐसा एप्लिकेशन जो अपना टनल इंटरफ़ेस रखता हो।
कोई भी पंक्ति लागू हो, लिखें कि टनल गिरने पर क्या होना चाहिए। चिह्न-आधारित मार्ग जो इंटरफ़ेस के साथ गायब हो जाता है, आमतौर पर भौतिक डिफ़ॉल्ट मार्ग पर लौटता है, जो fail-open व्यवहार है। यह ब्राउज़िंग के लिए स्वीकार्य हो सकता है और बाकी किसी भी चीज़ के लिए नहीं, और यह निर्णय है, कार्यान्वयन का विवरण नहीं।
उन प्रवाहों को जाँचें जिन्हें आप कवर करने का दावा करते हैं
स्वीकृति परीक्षण को उस सीमा का पालन करना चाहिए जो आपने लिखी, न कि उन पोर्ट संख्याओं का जो सुविधाजनक थीं। एक प्रवाह चुनें जो टनल से जाना चाहिए, एक जो नहीं जाना चाहिए, और एक जो ऐसे परिवहन का उपयोग करे जिसके बारे में आपने सोचा नहीं:
ip route get 203.0.113.40
curl -sS -o /dev/null -w 'v4 %{http_version} %{remote_ip}\n' https://example.com
nft list ruleset | grep -A2 'dport'मार्ग खोज बताती है कि कोई गंतव्य वास्तव में कौन-सा इंटरफ़ेस उपयोग करता है, और यही वह तथ्य है जिसे अधिकांश रिपोर्ट गलत कहती हैं। curl पंक्ति बातचीत किया गया संस्करण और पता-परिवार पुष्ट करती है। नियम-समुच्चय का डंप उस नियम को पकड़ता है जो आपने परीक्षण के दौरान जोड़ा और सीमित करना भूल गए, और इस तरह अस्थायी चिह्न स्थायी fail-open राउटिंग बन जाता है।
तीनों आउटपुट समय-मुद्रा के साथ दर्ज करें और उन्हें परिवर्तन के साथ रखें। जब बाद में कोई बताए कि «VPN ने इंट्रानेट तोड़ दिया», तब इच्छित सीमा और लागू की गई सीमा का अंतर उसी रिकॉर्ड में दिखेगा, और सुधार नियम बदलना होगा, बहस नहीं।