पोर्ट 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 ले इन्ट्रानेट बिगार्यो» भनी रिपोर्ट गर्दा, अभीष्ट र कार्यान्वित सीमाबीचको फरक त्यही अभिलेखमा देखिनेछ, र सुधार नियम बदल्नु हुनेछ, बहस होइन।