तुमची सार्वजनिक 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 किंवा इंटरफेसमधील पुढील बदल तो शांतपणे तोडू शकतो, आणि तीन मूल्ये नमूद करणारी टीप ग्राहक अहवालातून लक्षण पुन्हा शोधण्यापेक्षा वेगाने तपासता येते.

स्रोत-निर्दिष्ट शोध यशस्वी झाल्यानंतरही सेवा चुकीच्या मार्गाने उत्तर देत असेल, तर थेट सॉकेटचा स्रोत पत्ता नियमातील पत्त्याशी तुलना करा. वाइल्डकार्ड पत्त्याशी बांधलेली सेवा तुम्ही चाचणी केलेल्या पत्त्यापेक्षा वेगळा स्रोत निवडू शकते, आणि तीच विसंगती उरलेली तफावत आहे.