राउटेड किंवा ब्रिज्ड 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 विभागात सामील होण्यासाठी वेगळे समर्थन लागते, आणि ते बदलापूर्वी लिहिले पाहिजे.