तपाईंको सार्वजनिक Linux सेवाले किन VPN बाट जवाफ दिन्छ

सकेटमा कुनै पनि कुराले कुन इन्टरफेसले अनुरोध बोकेको थियो सम्झँदैन, त्यसैले पूर्ण-टनेल VPN को पूर्वनिर्धारित मार्गले WAN मा जानुपर्ने जवाफ समात्न सक्छ। सेवाले आउने इन्टरफेसलाई बेवास्ता गरिरहेको छैन; Linux ले स्थानीय रूपमा सिर्जना गरिएको जवाफलाई गन्तव्य र स्रोत नीतिअनुसार रुट गर्छ। स्रोत-आधारित नियमले यसको सट्टा सेवाका जवाफहरू मात्र पूर्ण WAN तालिकामार्फत पठाउन सक्छ, सामान्य आउटबाउन्ड टनेलमै छाडेर। जवाफ गलत मार्गबाट निस्कँदा पनि पोर्ट खुला रहन्छ, त्यसैले लक्षण एकतर्फी देखिन्छ।

गलत धारणा: जवाफहरू आएको इन्टरफेसलाई पछ्याउँछन्

eth0 मा आउने प्याकेट eth0 बाटै जानुपर्छ भन्ने तार्किक लाग्छ। स्थितिहीन प्याकेट फिल्टर यसरी लेख्न सकिन्छ, र आउनेतर्फको tcpdump ले अनुरोध ठ्याक्कै अपेक्षित ठाउँमा देखाउँछ। होस्ट आफैँले बनाउने ट्राफिकका लागि रुटिङ यसरी काम गर्दैन।

सेवाले जडान स्वीकार गरेपछि त्यसको जवाफ नयाँ स्थानीय रूपमा सिर्जना गरिएको प्याकेट हो। कर्नेलले जवाफको गन्तव्य र स्रोतका लागि रुटिङ नियमहरू हेर्छ, र VPN को पूर्वनिर्धारित मार्ग पूर्ण रूपमा वैध जवाफ हो। सकेटमा कुनै पनि कुराले कुन इन्टरफेसले अनुरोध बोकेको थियो सम्झँदैन।

त्यसैले लक्षण एकतर्फी देखिन्छ: अनुरोधहरू आउँछन्, जवाफहरू हराउँछन्। त्यसैले आउने पोर्टका लागि फायरवाल नियम थप्दा पनि केही बदलिँदैन। प्याकेट भित्र जाने बाटोमा रोकिएको छैन; बाहिर जाने बाटोमा अन्तै रुट गरिँदैछ। जवाफलाई स्रोत-निर्दिष्ट खोजले पछ्याउनुहोस्, घुम्ती देखिन थाल्छ।

कर्नेलले वास्तवमा के रुट गर्छ: स्रोत ठेगाना

तपाईंलाई चाहिने ह्यान्डल भनेको सेवाले जवाफका लागि प्रयोग गर्ने स्थानीय ठेगाना हो। eth0 ठेगाना उदाहरणका रूपमा 192.0.2.10/24 र गेटवे 192.0.2.1 भएको होस्टमा त्यो ठेगाना इन्टरफेसमा उपस्थित हुन्छ। क्लाउड VM मा सार्वजनिक ठेगाना माथि अनुवादित भई पाहुनामा नहुन सक्छ, त्यसैले होस्टसँग वास्तवमा भएको ठेगाना प्रयोग गर्नुहोस्।

तालिका नम्बर वा नियम प्राथमिकता आरक्षित गर्नुअघि हालको अवस्था जाँच्नुहोस्। विद्यमान नीति नियमहरूले नयाँलाई छाया पार्न सक्छन्, र एउटै नम्बरको पुरानो तालिकामा पहिले नै असम्बन्धित मार्गहरू हुन सक्छन्:

ip -4 addr show dev eth0
ip -4 rule show
ip -4 route show table all

त्यसपछि स्रोतअनुसार तालिका छान्नुहोस्। नियम पहिले नै 192.0.2.10 बोकेका जवाफहरूसँग मिल्छ, अर्थात् तपाईंले छुट दिन चाहेको स्थानीय रूपमा टुंगिएको ट्राफिक। अगाडि पठाइएको ट्राफिक र अन्य स्थानीय ठेगानाबाट आउने प्याकेट मिल्दैनन्।

आधा पूर्वनिर्धारित होइन, पूर्ण फिर्ती तालिका बनाउनुहोस्

केवल पूर्वनिर्धारित मार्ग भएको तालिका पर्याप्त हुँदैन। कर्नेलले अझै गेटवे समाधान गर्नुपर्छ, र त्यो समाधानका लागि एउटै तालिकामा जोडिएको प्रिफिक्स चाहिन्छ। त्यो प्रिफिक्स नभएको तालिका पूर्वनिर्धारित मार्ग ठीक देखिए पनि गेटवे समाधानमा असफल हुन्छ। दुवै थप्नुहोस्, त्यसपछि स्रोत नियम तालिकातर्फ निर्देशित गर्नुहोस्:

ip -4 route add table 100 192.0.2.0/24 dev eth0 src 192.0.2.10
ip -4 route add table 100 default via 192.0.2.1 dev eth0
ip -4 rule add priority 1000 from 192.0.2.10/32 lookup 100

उदाहरण प्रतिलिपि गर्नुको सट्टा वास्तविक प्रिफिक्स र गेटवे प्रयोग गर्नुहोस्। अन-लिङ्क गेटवेसहित /32 का रूपमा कन्फिगर गरिएको क्लाउड इन्टरफेसलाई फरक जोडिएको मार्ग चाहिन्छ, र गलत प्रिफिक्सबाट बनेको तालिका पहिलो हपमै असफल हुन्छ। src विशेषताले त्यो मार्गको रुचाइएको स्रोत जनाउँछ; यसले स्रोत नियमलाई प्रतिस्थापन गर्दैन।

क्रम पनि महत्त्वपूर्ण छ। कम प्राथमिकता नम्बर भएको फराकिलो नियम पहिले मूल्याङ्कन गरिन्छ, त्यसैले यो ट्राफिकलाई मुख्य तालिकामा फर्काउन सक्ने कुनै पनि नियमभन्दा पहिले स्रोत नियमसम्म पुग्नुपर्छ। थपेपछि ip rule show ले प्राथमिकताहरू जाँच्नुहोस्, बुटमा मात्र होइन।

स्रोत-निर्दिष्ट खोजले प्रमाणित गर्नुहोस्

कर्नेललाई सेवाको ठेगानाबाट परीक्षण गन्तव्यतर्फ रुट गर्न भन्नुहोस्। जवाफमा टनेल होइन, eth0 र WAN गेटवेको नाम हुनुपर्छ:

ip -4 route get 198.51.100.25 from 192.0.2.10

त्यसपछि नयाँ अधिकृत जडान स्थापना गरी दुवै दिशा हेर्नुहोस्। सही तालिका छान्ने खोजमा प्रत्यक्ष जडान अझै असफल भइरहे त्यसले तालिकालाई होइन, रिभर्स-पाथ फिल्टरिङ वा फायरवाल नियमतर्फ संकेत गर्छ। विश्वव्यापी रूपमा केही बन्द गर्नुअघि ती नियन्त्रणहरू जाँच्नुहोस्।

अन्तिम मार्गहरू र नियमलाई इन्टरफेसको मालिक नेटवर्क म्यानेजरअन्तर्गत राख्नुहोस्। ठेगाना परिवर्तन, DHCP नवीकरण र VPN पुनःजडानले सबै कर्नेल अवस्था पुनःलेखन गर्छन्, र हातले थपिएको नियम अर्को घटनापछि हराउँछ वा पुरानो गेटवेतर्फ संकेत गर्छ।

यो अपवाद कहाँ रोकिन्छ

नियमले एउटा स्रोत ठेगानाबाट स्थानीय रूपमा टुंगिएको ट्राफिकलाई छुट दिन्छ। यसले Docker ले प्रकाशित गरेका पोर्ट, DNAT वा होस्टमार्फत अगाडि पठाइएका सेवाहरू समेट्दैन, किनकि ती प्याकेटहरू अगाडि पठाइएको ट्राफिकका रूपमा रुट हुन्छन् र कहिल्यै उही तरिकाले होस्टको स्थानीय स्रोत बोक्दैनन्। त्यस्ता डिजाइनलाई सामान्यतया इनग्रेसमा राखिएको मार्क र त्यो मार्कसँग मिल्ने नियम चाहिन्छ।

यसले होस्टको सार्वजनिक ठेगाना इन्टरफेसमा देखाउँदैन। जब माथिको NAT त्यो ठेगानाको मालिक हुन्छ, जवाफ अझै त्यही मार्गबाट बाहिर निस्कनुपर्छ जुन त्यो NAT ले अपेक्षा गर्छ, त्यसैले WAN तालिकाले अनुमानित सार्वजनिक दायराको सट्टा मूल गेटवे र प्रिफिक्स प्रतिबिम्बित गर्नुपर्छ।

अपवादलाई यसको तालिका नम्बर, नियम प्राथमिकता र सटीक स्रोत ठेगानासहित अभिलेखित राख्नुहोस्। VPN वा इन्टरफेसमा आउने परिवर्तनले यसलाई चुपचाप तोड्न सक्छ, र तीन मानहरू उल्लेख गर्ने टिप्पणी ग्राहक प्रतिवेदनबाट लक्षण पुनः पत्ता लगाउनुभन्दा छिटो जाँचिन्छ।

स्रोत-निर्दिष्ट खोज सफल भएपछि पनि सेवाले गलत मार्गबाट जवाफ दिइरहेको छ भने, प्रत्यक्ष सकेटको स्रोत ठेगानालाई नियममा भएको ठेगानासँग तुलना गर्नुहोस्। वाइल्डकार्ड ठेगानामा बाँधिएको सेवाले तपाईंले परीक्षण गरेको ठेगानाभन्दा फरक स्रोत छान्न सक्छ, र त्यही असमानता बाँकी रहेको खाडल हो।