एउटा 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 ले काम गरिरहेको छ। भित्री क्याप्चर खाली छ भने समस्या टनेल वा फर्वार्डिङ नियममा छ, एडाप्टरको संख्यामा होइन। ती दुई क्याप्चर र राउटिङ तालिकाबाट टोपोलोजी तय गर्नुहोस्, अर्को परिवर्तनसँग तुलना गर्ने कुरा हुनेछ।