राउटेड या ब्रिज्ड VPN: क्लाइंट को क्या पहुँचना है, उसके आधार पर चुनें

एक ही दिन दो टिकट आते हैं: एक उपयोगकर्ता को आंतरिक वेब ऐप चाहिए, और एक इंजीनियर को बेंच उपकरण चाहिए जो ऐसे व्यवहार करे जैसे वह उसी Ethernet सेगमेंट पर हो। दोनों का जवाब उन्हें VPN पर डालो से दिया जाता है, और मुसीबत वहीं से शुरू होती है। राउटेड टनल और ब्रिज्ड टनल अलग-अलग रिश्ते फैलाते हैं, और हर अनुरोध से उनमें से सिर्फ एक मेल खाता है। टोपोलॉजी चुनना एक्सेस का फैसला है, क्रिप्टोग्राफी की सेटिंग नहीं।

टिकट डेस्क पर एक जैसी दिखने वाली दो माँगें

कर्मचारी की ज़रूरत एक सेवा है, जो IP पर उपलब्ध हो, ऐसे डिवाइस से जिसे आप नियंत्रित नहीं करते। इंजीनियर की ज़रूरत लिंक-स्तर पर है: उपकरण Ethernet फ्रेम और ब्रॉडकास्ट खोज देखने की अपेक्षा करता है, और शायद उस सेगमेंट से DHCP जिसमें वह खुद को मानता है।

ये अलग-अलग सवाल हैं, और दोनों का जवाब ब्रिज से देना कर्मचारी की पहुँच को बिना कारण पूरे ऑफिस LAN तक बढ़ा देता है।

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

राउट LAN सदस्यता से संकरा होता है

राउटेड क्लाइंट को टनल सबनेट पर पता और आपके चुने हुए प्रीफ़िक्स के लिए राउट मिलते हैं। अगर नीति ऐसा कहती है, तो वह एप्लिकेशन सर्वर तक पहुँच सकता है और किसी और जगह नहीं। गेटवे प्रवर्तन-बिंदु बन जाता है, बशर्ते हर प्रासंगिक रास्ता उसे पार करे।

राउट को अनुमति से न मिलाएँ। क्लाइंट को सबनेट तक पहुँचने का तरीका बताना उसे दूसरा गंतव्य आज़माने से नहीं रोकता।

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

ब्रिज प्रवेश का सवाल बदल देता है

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

तय करें कि कौन-से उपकरण जुड़ सकते हैं, कौन-से फ्रेम प्रकार पार होने चाहिए और कहाँ अनचाही अंतःक्रिया रोकी जाती है। एड्रेसिंग और DHCP अधिकार साझा नेटवर्क का हिस्सा बन जाते हैं, और एक सेगमेंट पर दो DHCP सर्वर ठीक वही गड़बड़ पैदा करते हैं जिसकी आप उम्मीद करते हैं।

उपकरण के लिए, समर्पित टेस्ट सेगमेंट आमतौर पर ऑफिस LAN से बेहतर बैठता है। प्रबंधन पहुँच को प्रयोग से बाहर रखें, और तय करें कि काम खत्म होने पर अस्थायी भागीदार कैसे हटाया जाएगा।

फ़िल्टरिंग दोनों टोपोलॉजी में मौजूद है

ब्रिज स्वभाव से अफ़िल्टर-योग्य नहीं है, और राउट स्वभाव से सुरक्षित नहीं है। Linux ब्रिज फ़िल्टरिंग के अपने हुक और अपनी नियम-वाक्यरचना है, और राउटेड IP फ़ॉरवर्डिंग के लिए लिखा नियम ब्रिज्ड फ्रेम पर अपने आप लागू नहीं होता।

सीमा का वादा करने से पहले जाँचें कि प्लेटफ़ॉर्म वास्तव में क्या समर्थन करता है:

bridge link show
nft list ruleset

TUN और TAP इंटरफ़ेस के ट्रैफ़िक का वर्णन करते हैं, साइफ़र का नहीं। इंटरफ़ेस बदलना इनमें से कुछ भी ठीक नहीं करता: पीयर प्रमाणीकरण, चोरी हुई कुंजी और पुरानी क्रिप्टोग्राफ़िक नीति सब बदलाव के बाद भी बनी रहती हैं। दोनों सिरों को अब भी ऐसी सेटिंग्स चाहिए जो मेल खाएँ और अब भी समर्थित हों।

तीन प्रयासों से सीमा साबित करें

स्वीकृति तीन अवलोकन हैं, डायग्राम की समीक्षा नहीं। माँगा गया संचालन काम करना चाहिए, असंबंधित गंतव्य विफल होना चाहिए, और गेटवे की अपनी प्रबंधन सेवाएँ पहुँच से बाहर रहनी चाहिए।

एक ही क्लाइंट से अनुमत और अस्वीकृत दोनों रास्ते चलाएँ, और दोनों दर्ज करें:

curl -sS -o /dev/null -w "%{http_code}" http://10.20.0.10/health
ip route get 10.20.0.10
ip route get 10.30.0.5

ब्रिज के लिए लिंक-स्तरीय जाँचें जोड़ें: अनुमत खोज ट्रैफ़िक पार होता है या नहीं, एड्रेसिंग इच्छित प्राधिकरण से आती है या नहीं, और हटाने के बाद अस्थायी भागीदार गया या नहीं। जब सादा राउटेड IP पहले ही ज़रूरत पूरी करता है, तब ऑफिस Ethernet सेगमेंट से जुड़ने के लिए अलग औचित्य चाहिए, और वह बदलाव से पहले लिखा जाना चाहिए।