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 नियम थप्ने कारण होइन।