रुटेड वा ब्रिज्ड 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 खण्डमा सामेल हुन छुट्टै औचित्य चाहिन्छ, र त्यो परिवर्तन अघि लेखिनुपर्छ।