आपकी सार्वजनिक Linux सेवा VPN से क्यों उत्तर देती है

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

गलत धारणा: उत्तर उसी इंटरफ़ेस का अनुसरण करते हैं जिस पर वे आए

यह तार्किक लगता है कि eth0 पर आने वाला पैकेट eth0 से ही जाए। स्टेटलेस पैकेट फ़िल्टर इस तरह लिखे जा सकते हैं, और आने वाली ओर tcpdump अनुरोध को ठीक वहीं दिखाता है जहाँ अपेक्षा होती है। होस्ट द्वारा स्वयं बनाए गए ट्रैफ़िक के लिए रूटिंग ऐसे काम नहीं करती।

सेवा के कनेक्शन स्वीकार करने के बाद उसका उत्तर एक नया स्थानीय रूप से बनाया गया पैकेट होता है। कर्नेल उत्तर के गंतव्य और स्रोत के लिए रूटिंग नियम देखता है, और VPN का डिफ़ॉल्ट मार्ग पूरी तरह वैध उत्तर है। सॉकेट में कुछ भी याद नहीं रखता कि किस इंटरफ़ेस ने अनुरोध ढोया था।

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

कर्नेल वास्तव में क्या रूट करता है: स्रोत पता

आपको जो हैंडल चाहिए वह स्थानीय पता है जो सेवा उत्तरों के लिए उपयोग करती है। 192.0.2.10/24 जैसे उदाहरण eth0 पते और 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 या इंटरफ़ेस में अगला परिवर्तन इसे चुपचाप तोड़ सकता है, और तीनों मानों का नाम लेने वाला नोट ग्राहक रिपोर्ट से लक्षण फिर से खोजने की तुलना में तेज़ी से जाँचा जा सकता है।

यदि स्रोत-योग्य लुकअप सफल होने के बाद भी सेवा गलत पथ से उत्तर देती है, तो लाइव सॉकेट के स्रोत पते की तुलना नियम वाले पते से करें। वाइल्डकार्ड पते से बंधी सेवा आपके परीक्षण किए गए पते से भिन्न स्रोत चुन सकती है, और वही बेमेल बचा हुआ अंतर है।