स्थानिक ॲप, 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 रचना ती व्याप्ती टिकवू शकते का ते तपासा।