स्थानीय एप, VPN नियम: तपाईंको FORWARD चेन किन कहिल्यै सक्रिय हुँदैन
मेसिनमा चल्ने प्रक्रियाले OUTPUT प्रयोग गर्छ, FORWARD होइन। सही namespace मा hook छान्नुहोस्, त्यसपछि mark वा साधारण route पर्याप्त छ कि भनेर निर्णय गर्नुहोस्।
तपाईं FORWARD चेनमा VPN ट्राफिकका लागि नियम थप्नुहुन्छ, त्यही Linux बक्सबाट अनुरोध चलाउनुहुन्छ, र काउन्टर शून्यमै रहन्छ। नियम सम्भवतः सही छ। प्याकेटले त्यो बाटो कहिल्यै लिएन, किनकि मेसिनमै उत्पन्न भएको अनुरोध यसले अगाडि पठाउँदैन। सकेटदेखि तारसम्म प्याकेटको जीवन पछ्याउँदा यो किन हुन्छ र नियम वास्तवमा कहाँ हुनुपर्छ भन्ने स्पष्ट हुन्छ।
प्याकेट कहाँ जन्मियो पत्ता लगाउनुहोस्
Netfilter को hook क्रमले तीन अवस्था छुट्याउँछ, र तीमध्ये एउटामा मात्र FORWARD पर्छ:
| Origin | Path | Hook that sees it |
|---|---|---|
| Local process | OUTPUT then POSTROUTING | OUTPUT, POSTROUTING |
| Addressed to a local service | PREROUTING then INPUT | PREROUTING, INPUT |
| Received for another host | PREROUTING, FORWARD, POSTROUTING | FORWARD |
स्थानीय एप्लिकेसन OUTPUT मार्गमा सुरु हुन्छ, किनकि कर्नेलले पहिले नै निर्धारण गरिसकेको छ कि प्याकेट यहीँ उत्पन्न हुन्छ र कहिल्यै अगाडि पठाउने उम्मेदवार होइन। टनेल बनाउँदा त्यो वर्गीकरण बदलिँदैन; टनेल त्यस्तो उपकरण हो जसबाट प्याकेट बाहिर जान सक्छ, स्थानीय आउटपुटलाई ट्रान्जिट बनाउने चरण होइन।
दुई प्याकेट, एउटै कथा
टनेल उठेपछि एपको भित्री प्याकेट र इन्क्रिप्ट गरिएको बाहिरी प्याकेट फरक वस्तु हुन्। भित्री प्याकेटले एपले छानेको गन्तव्य र पेलोड बोक्छ। बाहिरी प्याकेटले साइफरटेक्स्ट पीयरको ठेगाना र पोर्टमा लैजान्छ, र भौतिक इन्टरफेस वास्तवमा त्यही पार गर्छ।
तपाईंको नीति तीमध्ये एउटासँग सम्बन्धित छ, र गलत छान्नु नियम केही गर्दैन जस्तो देखिने सामान्य कारण हो। पीयरको बाहिरी ठेगानासँग मिल्ने नियमले हरेक टनेल प्याकेटलाई एउटै रूपमा देख्छ, भित्रको एपले जे गरे पनि। भित्री गन्तव्यसँग मिल्ने नियमले तपाईंलाई महत्त्वपूर्ण ट्राफिक देख्छ, र त्यो प्याकेट तपाईंले नियम राखेको hook सम्म पुगेपछि मात्र सक्रिय हुन्छ।
namespace ले सीमा सार्छ
कन्टेनरले सिद्धान्त नबदली यसलाई कठिन बनाउँछ। एपको अनुरोध कन्टेनरको नेटवर्क namespace भित्रको स्थानीय आउटपुट हो। होस्टले त्यो ट्राफिक भर्चुअल Ethernet इन्टरफेसमा लिन्छ र अगाडि पठाउन सक्छ, त्यसैले होस्टमा राखिएको FORWARD नियम अर्थपूर्ण हुन सक्छ, यद्यपि अनुरोध सिर्जना गर्ने प्रक्रियाले होस्टको OUTPUT चेन कहिल्यै छोएन।
hook छान्नुअघि नियमसमूह र टनेल वास्तवमा कहाँ बस्छन् निर्धारण गर्नुहोस्। कन्टेनरभित्रको टनेल, कन्टेनरलाई त्यसबाट route गरिएको होस्टको टनेल, र छुट्टै namespace को टनेल तीन फरक टोपोलोजी र तीन फरक नियम-स्थान हुन्। उपकरणको स्वामित्व भएको namespace भित्र नियम पढ्नुहोस्, डिफोल्टमा मात्र होइन।
mark चाहिन्छ कि भनेर सोध्नुहोस्
यदि लक्ष्य एउटा गन्तव्य प्रिफिक्स टनेलबाट पठाउनु हो भने, त्यो प्रिफिक्सका लागि route पर्याप्त हुन सक्छ। पहिले प्रभावकारी route जाँच्नुहोस्, सर्भरले धकेलेका सबै कुरा सहित: पुनर्निर्देशित डिफोल्टले तपाईंले सोचेको साँघुरो नीतिभन्दा धेरै बढी ट्राफिक VPN बाट पठाउँछ, र जतिसुकै mark गरे पनि नतिजा उद्देश्यसँग मिल्दैन।
निर्णय route व्यक्त गर्न नसक्ने कुनै कुरामा निर्भर हुँदा वर्गीकरण आवश्यक हुन्छ, जस्तै स्रोत, प्रयोगकर्ता वा प्रक्रिया। प्राप्त ट्राफिकका लागि PREROUTING मा mark काम गर्छ। स्थानीय ट्राफिकका लागि mark यस्तो आउटपुट चरणमा हुनुपर्छ जसले mark राखेपछि नयाँ route खोज सुरु गर्न सकोस्। nftables मा त्यो आउटपुट hook मा route प्रकारको चेन हो; साधारण आउटपुट फिल्टर चेनले मान राखेर route अपरिवर्तित छोड्छ।
iptables मा समतुल्य कुरा mangle OUTPUT व्यवस्थामा बस्छ, र त्यही सर्त लागू हुन्छ: mark अस्तित्वमा आएपछि route निर्णय फेरि हेर्नुपर्छ। त्यसपछि नीति-नियमले mark खपत गरेर उपयोगी route भएको तालिकामा देखाउनुपर्छ। conntrack mark राख्नु तेस्रो, छुट्टै अपरेसन हो; यसले प्रवाहमा मान राख्छ र त्यो मान आफैँले हालको प्याकेटमा राखेर route लाई पढ्न दिँदैन।
खोज र काउन्टर सँगै जाँच्नुहोस्
nft list ruleset
ip route get 198.51.100.25
ip route get 198.51.100.25 mark 0x1ठेगाना र mark उदाहरण हुन्, र दुई route प्रश्नले फरक प्रश्नको उत्तर दिन्छन्। दोस्रोले प्याकेटमा त्यो mark भए कर्नेलले के गर्थ्यो भनेर सोध्छ; यसले तपाईंको नियमसमूहले mark दिन्छ भनी देखाउँदैन। यसलाई परिकल्पना-परीक्षण मान्नुहोस्, नीति काम गर्छ भन्ने प्रमाण होइन।
त्यसपछि निर्दोष अनुरोध चलाउनुहोस् र एकैचोटि दुई कुरा हेर्नुहोस्: तपाईंले छानेको hook को काउन्टर, र प्याकेटले वास्तवमा लिएको निर्गम। काउन्टर बढ्यो र प्याकेट अन्तैबाट निस्कियो भने mark वा तालिका गलत छ। दुवै बढेनन् भने प्याकेट त्यो hook सम्म पुग्दैन, र अर्को प्रश्न namespace वा मार्ग हो।
अन्तमा, परीक्षणलाई संयन्त्रले व्यक्त गर्न सक्ने कुरामै सीमित राख्नुहोस्। एउटा ठेगानाका लागि एउटा route, ठेगाना बदलिने सेवाका लागि स्थायी नीति बन्दैन। पहिले प्याकेटको दायरा तय गर्नुहोस्, त्यसपछि पुनः जोडिएपछि पनि route र mark डिजाइनले त्यो दायरा टिकाउन सक्छ कि भनेर जाँच्नुहोस्।