पोर्ट 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 डीफॉल्ट पोर्ट 443 असलेले UDP वापरते।
दिलेला ब्राउझर 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 ने इंट्रानेट तोडले» असे नोंदवल्यावर, इच्छित आणि अंमलात आणलेल्या सीमेतील फरक त्या नोंदीत दिसेल, आणि दुरुस्ती नियम बदलणे असेल, वाद नाही।