VPN पोर्ट उघडल्याने क्लायंट LAN पर्यंत पोहोचत नाहीत

टनेल वर येतो, क्लायंट प्रमाणित होतो, पण गेटवेच्या मागील LAN अदृश्य राहतो. हे दुरुस्त करायच्या नियमाने VPN पोर्टला परवानगी दिली आहे आणि तो जसाच्या तसा काम करतो, कारण तो नियम गेटवेलाच पाठवलेल्या पॅकेटवर लागू होतो. गेटवेच्या मागील होस्टसाठी जाणाऱ्या क्लायंट रहदारीचे गंतव्य वेगळे आणि साखळी वेगळी आहे. यशस्वी लॉगिन कर्नेल कोणती साखळी पाहतो हे बदलत नाही.

दोन साखळ्या, दोन वेगळी गंतव्ये

पॅकेटचे भवितव्य ते कुठे जाते यावर ठरते, ते कसे आले यावर नाही. गेटवेवरील पत्त्याकडे जाणारी रहदारी स्थानिक पातळीवर पोहोचवली जाते आणि इनपुट नियमांनी तपासली जाते. गेटवे पुढे पाठवणारी रहदारी फॉर्वर्डिंग नियमांनी तपासली जाते. एकच टनेल इंटरफेस दोन्ही प्रकारची पॅकेट तयार करू शकतो, म्हणून एक नियम दोन्ही कामे झाकू शकत नाही.

संपूर्ण दंतकथा एका वाक्यात: श्रोत्याला परवानगी देणे त्याच्या मागील नेटवर्कला परवानगी देण्याबद्दल काहीच सांगत नाही. हे वेगळ्या पुराव्यांसह दोन वेगळे निर्णय आहेत, आणि दोन्हींवर इंटरफेसचे नाव असणे त्यांना एक करत नाही.

श्रोता नियम प्रत्यक्षात काय परवानगी देतो

श्रोत्याची पॅकेट VPN प्रक्रियेत संपतात, आणि त्यामुळेच टनेल उभारणे शक्य होते. गेटवेचे प्रशासन पृष्ठ आणि स्थानिक निदान उत्तरही होस्टचाच इनपुट मार्ग वापरतात, म्हणून गेटवेकडील चाचणी यशस्वी होते तर त्याच्या मागील सर्व काही अपयशी ठरते. दोन्ही निकाल बरोबर आहेत आणि कोणताही LAN बद्दल नाही.

जेव्हा प्रक्रिया दुसऱ्या गंतव्यासाठी क्लायंट रहदारी डीकॅप्स्युलेट करते, तेव्हा पॅकेट फॉर्वर्डिंग मार्गात येते आणि तिथे परवानगी लागते. यशस्वी प्रमाणीकरण क्लायंट कोण आहे हे ठरवते; तो कुठे जाऊ शकतो हे ठरवत नाही. दोन्ही प्रश्नांना वेगळे मालक, वेगळे लॉग आणि वेगळे त्रुटी संदेश आहेत.

क्लायंटकडून चाचणी करा, गेटवेकडून कधीही नाही

गेटवेवर तयार केलेली चाचणी होस्टच्या स्वतःच्या आउटपुट मार्गाने जाते आणि फॉर्वर्डिंग मार्ग बंद असतानाही यशस्वी होऊ शकते. चाचणी क्लायंटपासून सुरू करा आणि प्रवाहाची दोन्ही टोके पाहा.

nc -vz 10.40.7.25 445
tcpdump -ni tun0 host 10.40.7.25

जर विनंती tun0 वर दिसली आणि गंतव्यापर्यंत काहीही पोहोचले नाही, तर पॅकेट आल्यानंतर टाकून दिले जाते, जे फॉर्वर्डिंग नियम किंवा गंतव्याच्या स्वतःच्या फिल्टरिंगकडे निर्देश करते. जर tun0 वर काहीच दिसले नाही, तर क्लायंट ती टनेलमध्येही पाठवत नाही, आणि समस्या गेटवे धोरणात नाही तर क्लायंटच्या राउटिंगमध्ये आहे. बरोबर बाहेर जाऊन काहीही परत न करणाऱ्या विनंतीशी याची तुलना करा, जी परतीच्या मार्गाची गोष्ट आहे.

फॉर्वर्डिंगला एक नाही, तीन गोष्टी लागतात

कर्नेल फॉर्वर्डिंग सक्रिय असणे, फिल्टर नियमाने प्रवाह स्वीकारणे, आणि गंतव्यापर्यंत पोहोचता येणे व उत्तर परत येण्याचा मार्ग असणे आवश्यक आहे. तीनपैकी एक नसेल तर क्लायंटच्या दृष्टीने तीच शांतता.

sysctl net.ipv4.ip_forward
sudo iptables -S FORWARD
sudo iptables -S INPUT

तीनही आउटपुट एकत्र वाचा. पहिल्यात शून्य असेल तर उर्वरित दोन निरर्थक. दुसऱ्यात मूलभूत-टाकून देण्याचे धोरण असेल तर क्लायंटची पॅकेट टाकून दिली जातात, गेटवेची स्वतःची रहदारी मात्र चालू राहते. तिसरे आउटपुट श्रोता नियम कधीच समस्या नव्हता हे दाखवते.

दस्तऐवजात दोन्ही नियम संच वेगळे ठेवा

श्रोता नियम आणि फॉर्वर्ड केलेल्या सेवेचा नियम वेगळ्या ओळींत, वेगळ्या मालकांसह आणि कारणांसह लिहा. VPN पोर्ट बदलला किंवा नवीन सेवा प्रकाशित झाली, तर ते विभाजन एका बदलाला दुसरा शांतपणे रुंदावण्यापासून थांबवते.

प्रत्येक प्रमाणित सहकार्याला विश्वासार्ह LAN सदस्य मानण्याऐवजी, आवश्यक क्लायंट श्रेणी आणि सेवांसाठी अरुंद नियम वापरा. StrongSwanच्या फॉर्वर्डिंग टिपा त्याच सीमेची परतीची मार्ग आणि भाषांतर बाजू वर्णन करतात, जो पुन्हा तिसरा निर्णय आहे.

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