एक NIC की दोन? VPN सर्व्हरचे इंटरफेस लेआउट ठरवणे

अनेक VPN सर्व्हरसाठी एकच फिजिकल अॅडॉप्टर पुरतो, आणि ते सार्वत्रिक रचनाही नाही. एन्क्रिप्टेड कनेक्शन त्या अॅडॉप्टरवर येते, VPN प्रोसेस ते डिक्रिप्ट करते, आणि नंतर आतील ट्रॅफिक व्हर्च्युअल इंटरफेसतून बाहेर पडते, स्थानिक सेवा किंवा राउटेड LAN पर्यंत पोहोचण्यापूर्वी. हे चालते की नाही हे तीन अटींवर अवलंबून आहे: गंतव्य कुठे आहे, LAN कडे क्लायंट पूलपर्यंत परतीचा मार्ग आहे का, आणि एक सामायिक फिजिकल लिंक तुम्ही दावा करता ते अलगीकरण देते का. या तिन्हींना उत्तर द्या आणि अॅडॉप्टरची संख्या त्यातून येईल.

हे ठरवणाऱ्या तीन अटी

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

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

यापैकी एकही चेसिसवरील पोर्टच्या संख्येबद्दल नाही. त्या राउटिंग, पत्त्यांची मालकी आणि रचना किती फिजिकल विभक्तीकरणावर अवलंबून आहे याबद्दल आहेत.

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

सेवा VPN होस्टवर चालते तेव्हा

सर्वात सोप्या प्रकरणात फॉर्वर्डिंगची अजिबात गरज नसते. डिमन टनेल इंटरफेसवर क्लायंटचे पॅकेट घेतो आणि स्थानिक सॉकेटला देतो, आणि प्रतिसाद त्याच इंटरफेसने परत येतो. होस्टच्या दृष्टीने क्लायंट पूलचा पत्ता खरा स्थानिक पत्ता असतो.

तरीही दोन गोष्टी बरोबर असल्या पाहिजेत: सेवेने टनेल पोहोचू शकेल अशा पत्त्यावर ऐकले पाहिजे, आणि होस्टच्या फायरवॉलने टनेल इंटरफेसवर येणारा ट्रॅफिक स्वीकारला पाहिजे. दोन्ही खालील कमांडमध्ये दिसतात.

ss -lntup | grep -E "5432|8080"
ip -brief addr show
ip route get 10.8.0.6 from 10.8.0.1

सेवा केवळ सार्वजनिक पत्त्यावर बांधणे, किंवा चुकून टनेल इंटरफेस फिल्टर करणे, असे कनेक्शन तयार करते जे होस्टपर्यंत पोहोचते आणि नंतर मरते. हे VPN बिघाडासारखे दिसते आणि सहसा सॉकेट किंवा फायरवॉलचा निर्णय असतो.

जेव्हा गंतव्य LAN वर असते

इथेच एका अॅडॉप्टरची रचना अवघड असल्याची ख्याती मिळवते. सर्व्हरने क्लायंटचे पॅकेट LAN कडे फॉर्वर्ड केले पाहिजेत, आणि LAN उपकरणाने प्रतिसाद क्लायंट पूलकडे परत पाठवले पाहिजेत. एकतर तो पूल LAN वर मार्ग म्हणून वाहा, किंवा सर्व्हरवर स्रोत पत्ता भाषांतरित करा जेणेकरून प्रतिसाद सर्व्हरकडेच परत येतील.

दोन्ही उत्तरे कायदेशीर आहेत आणि ती वेगळ्या पद्धतीने अयशस्वी होतात. परतीचा मार्ग मूळ क्लायंट पत्ता गंतव्याला दिसत ठेवतो, जे लॉगसाठी चांगले आणि LAN पत्ते गृहीत धरणाऱ्या फायरवॉल नियमांसाठी वाईट. भाषांतर LAN सोपे ठेवते आणि गंतव्यापासून क्लायंटची ओळख लपवते.

sysctl net.ipv4.ip_forward
nft list ruleset | grep -A4 'chain forward'
ip route show table main | grep 10.8.0

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

alias दुसरा झोन का तयार करत नाही

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

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

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

तुम्ही परवानगी देता त्या ट्रॅफिकशी लेआउट तपासा

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

मग डिझाइन दस्तऐवजातील आकृतीऐवजी प्रत्यक्ष इंटरफेस आणि प्रत्यक्ष कॅप्चर तपासा. खालील कमांड दोन्ही दृश्ये छापतात.

ip -brief addr
ip route
tcpdump -ni any udp port 51820 -c 5
tcpdump -ni tun0 -c 5

बाह्य कॅप्चर एन्क्रिप्टेड ट्रॅफिक दाखवत असेल आणि अंतर्गत कॅप्चर टनेल इंटरफेसवरील डिक्रिप्टेड ट्रॅफिक दाखवत असेल, तर फिजिकल अॅडॉप्टर दोन्ही वाहत असेल, तर एकच NIC काम करत आहे. अंतर्गत कॅप्चर रिकामे असेल, तर समस्या टनेलमध्ये किंवा फॉर्वर्डिंग नियमांमध्ये आहे, अॅडॉप्टरच्या संख्येत नाही. त्या दोन कॅप्चर आणि राउटिंग टेबलवरून टोपोलॉजी ठरवा, आणि पुढील बदलाला तुलना करण्यासाठी काहीतरी असेल.