एक 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

असममित मार्ग इसका क्लासिक लक्षण है: क्लाइंट का अनुरोध पहुँचता है, जवाब किसी दूसरे राउटर से निकलता है, और कनेक्शन बिना किसी त्रुटि के दोनों सिरों पर टाइम आउट हो जाता है। टनल के बारे में कोई नतीजा निकालने से पहले दोनों तरफ़ कैप्चर करें।

उपनाम दूसरा ज़ोन क्यों नहीं बनाता

उसी एडाप्टर पर दूसरा पता जोड़ना, या दूसरे पोर्ट की नक़ल के लिए डमी इंटरफ़ेस बनाना, बहुत कम बदलता है। पैकेट अब भी उसी फ़िज़िकल लिंक, उसी स्विच पोर्ट और आम तौर पर उसी फ़ायरवॉल चेन से बाहर जाते हैं, इसलिए उनके बीच कोई नई सीमा नहीं बनती। यह कॉन्फ़िगरेशन की सुविधा है, सेगमेंटेशन नहीं। इसे ज़ोन की सीमा मानना वही तरीक़ा है जिससे आइसोलेशन का दावा केवल काग़ज़ पर बचता है।

अलग ज़ोन के लिए मार्ग में असली अलगाव चाहिए, और दूसरा एडाप्टर यही शर्त पूरी करता है। अगर कोई नियम इस बात पर निर्भर है कि VPN की ओर जाने वाला ट्रैफ़िक LAN की ओर जाने वाले ट्रैफ़िक के साथ कभी ब्रॉडकास्ट डोमेन साझा न करे, तो एक केबल यह गुण नहीं दे सकता, चाहे होस्ट को कैसे भी पता दिया जाए।

जहाँ कोई उत्पाद किसी विशिष्ट मोड के लिए मल्टी-इंटरफ़ेस टोपोलॉजी का दस्तावेज़ीकरण करता है, वहाँ कोई कामचलाऊ उपाय गढ़ने के बजाय उसी उत्पाद के दस्तावेज़ का पालन करें। विक्रेता रिलीज़ के बीच समर्थित टोपोलॉजी भी बदलते हैं, जो पुराने विज़ार्ड स्क्रीनशॉट के बजाय मौजूदा गाइड पढ़ने का एक और कारण है।

अपनी अनुमत ट्रैफ़िक के सामने लेआउट जाँचें

उन ट्रैफ़िक श्रेणियों की सूची बनाएँ जो सर्वर को ले जानी हैं: क्लाइंट से होस्ट, क्लाइंट से LAN, होस्ट से LAN, और एन्क्रिप्टेड बाहरी कनेक्शन। हर श्रेणी का एक स्रोत, एक गंतव्य और एक इंटरफ़ेस होता है, और लेआउट को चारों एक साथ पूरे करने होते हैं। जो डिज़ाइन इनमें से तीन संभालता है, वही आम तौर पर टिकट पैदा करता है।

फिर डिज़ाइन दस्तावेज़ के चित्र के बजाय वास्तविक इंटरफ़ेस और वास्तविक कैप्चर की पुष्टि करें। नीचे दिए कमांड दोनों दृश्य दिखाते हैं।

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

अगर बाहरी कैप्चर एन्क्रिप्टेड ट्रैफ़िक दिखाता है और अंदरूनी कैप्चर टनल इंटरफ़ेस पर डिक्रिप्टेड ट्रैफ़िक दिखाता है, जबकि फ़िज़िकल एडाप्टर दोनों ले जाता है, तो एक ही NIC काम कर रहा है। अगर अंदरूनी कैप्चर खाली है, तो दिक्कत टनल या फ़ॉरवर्डिंग नियमों में है, एडाप्टरों की संख्या में नहीं। टोपोलॉजी का फ़ैसला उन दो कैप्चर और राउटिंग टेबल से करें, और अगले बदलाव के पास नापने के लिए कुछ होगा।