पोर्ट फॉरवर्डिंगशिवाय NAT मागील वर्कस्टेशनपर्यंत पोहोचा
इनबाउंड पोर्ट नसलेल्या वर्कस्टेशनपर्यंतही हब, रिले किंवा ॲप ब्रोकरमार्फत पोहोचता येते। एक निवडण्यापूर्वी प्रत्येक रचना काय हमी देते याची तुलना करा।
कॅरियर NAT आणि लॉक केलेल्या कार्यालयीन राउटरमागील दोन एंडपॉइंट फॉरवर्ड करण्यासाठी एकही इनबाउंड पोर्ट सोडत नाहीत, आणि प्रतिक्रिया तरीही एक मागण्याची असते। अधिक चांगला प्रश्न असा आहे की कोणती बाजू बाहेर डायल करू शकते आणि कोणत्या पोहोचण्यायोग्य सेवेला रहदारी वाहून नेण्याची परवानगी आहे। चार रचना या प्रश्नाचे वेगवेगळे उत्तर देतात, आणि मार्ग अडवला गेल्यावर त्या वेगवेगळ्या प्रकारे अपयशी होतात। त्यांच्यातील निवड ही प्रोटोकॉल नावांची नसून हमींची तुलना आहे।
चार रचना, चार वेगवेगळी वचने
खालील तक्ता ही थोडक्यात आवृत्ती आहे। मधला स्तंभ तुम्ही तपासू शकता असे वचन म्हणून, आणि उजवा स्तंभ कोणीही न दिलेले वचन म्हणून वाचा।
| Design | Who initiates | Promise you get | Promise you do not get |
|---|---|---|---|
| Routed VPN hub | Both ends, outbound to the hub | A routed path to permitted prefixes | Access to services no policy allows |
| Peer traversal with ICE | Both peers to a rendezvous service | A path tested between the two peers | A direct path through every NAT |
| TURN relay | Client outbound to a relay | Transport that survives symmetric NAT | Peer discovery or a usable directory |
| Application broker | Workstation outbound to a broker | One audited application session | Subnet-wide reachability |
कोणती ओळ लागू होते हे पसंतीवर नाही, कामावर अवलंबून असते। एक दूरस्थ डेस्कटॉप सत्र, एक प्रशासकीय शेल आणि संपूर्ण खाजगी सबनेटमध्ये प्रवेश — या तीनही आवश्यकता आहेत ज्यांना एकच प्रवेशबिंदू लागत नाही, जरी त्या योगायोगाने एकाच मशीनशी संबंधित असल्या तरी।
हब कोण बाहेर डायल करतो हे बदलतो, काय परवानगी आहे ते नाही
राउटेड हब रचनेत दूरचा लॅपटॉप आणि वर्कस्टेशन, किंवा त्याच्यासमोरील साइट गेटवे, प्रत्येकजण दोघांनाही पोहोचण्यायोग्य अशा सेवेकडे बाहेर जाणारी टनेल उघडतात। वर्कस्टेशनच्या राउटरवर काहीही न मागितलेले कनेक्शन स्वीकारत नाही, आणि याच कारणामुळे ही रचना NAT मागे टिकते आणि साइटकडे स्थिर पत्ता नसतानाही काम करते। त्यानंतर हब स्वतःच्या धोरणानुसार दोन आंतरिक पत्त्यांमधील रहदारी राउट करते।
किंमत अशी आहे की हब अस्तित्वात असले पाहिजे, दोन्ही बाजूंनी पोहोचण्यायोग्य असले पाहिजे आणि कोणीतरी ते चालवले पाहिजे। बाहेर जाणाऱ्या फिल्टरिंगने वाहतुकीला परवानगी दिली पाहिजे, आणि ती अडवणारे नेटवर्क पोर्ट फॉरवर्डिंगची गरज नसतानाही रचना उद्ध्वस्त करेल।
सूक्ष्म भाग असा आहे की पोहोचता येणे आणि अधिकृतता या वेगवेगळ्या ठिकाणी घेतल्या जाणाऱ्या स्वतंत्र निर्णय आहेत। प्रीफिक्समधील मार्ग वर्कस्टेशनवरील कोणती सेवा ओळख वापरू शकते हे सांगत नाही, आणि टनेलला परवानगी देणारा फायरवॉल नियम खाते लॉग इन करू शकते का हे सांगत नाही। दोन्ही संरचीत करा, दोन्ही तपासा, आणि अधिकृततेचा निर्णय राउटिंग तक्त्याकडे नाही तर संसाधनाची मालकी असलेल्या प्रणालीकडे ठेवा।
दोन्ही स्टॅक ती अंमलात आणतात तेव्हाच ट्रॅव्हर्सल काम करते
समकक्ष टोकांमधील ट्रॅव्हर्सल ही विशिष्ट प्रणालीची क्षमता आहे, VPN सुधारणारी सेटिंग नाही। Interactive Connectivity Establishment अनेक उमेदवार पत्ते गोळा करते आणि एक काम करेपर्यंत जोड्या तपासते: स्थानिक इंटरफेसवरील होस्ट उमेदवार, NAT जे उघड करते त्यावरून तयार केलेले सर्व्हर-प्रतिबिंब उमेदवार, आणि रिलेवर वाटलेले रिले उमेदवार। फक्त खाजगी पत्ता मार्ग नाही, कारण दुसरी बाजू तिथे राउट करू शकत नाही।
रिले होणारे प्रकरण बाजूला टाकण्यापूर्वी समजून घेणे योग्य आहे। RFC 8656 TURN चे वर्णन अशा प्रोटोकॉल म्हणून करते ज्यामध्ये क्लायंट सर्व्हरकडे रिले केलेला वाहतूक पत्ता मागतो आणि सर्व्हर त्या क्लायंट आणि त्याच्या समकक्षांमध्ये रहदारी पाठवतो। त्यामुळे डेटा रिले वाहतो, जे केवळ टोकांना भेटण्यास मदत करणाऱ्या निर्देशिकेपेक्षा मूलभूतपणे वेगळे आहे। रिले पत्ता दुसऱ्या बाजूशी देवाणघेवाण करणे हे ॲप्लिकेशनने करावयाचे समन्वयाचे पाऊल आहे।
तुम्ही वचन देऊ शकत नाही तो थेट मार्ग। सममितीय NAT आणि काही एंटरप्राइझ फायरवॉल छिद्र पाडण्याला पराभूत करतात, आणि असे झाल्यावर प्रणाली एकतर रिलेवर माघार घेते किंवा अपयशी होते। तसेच दोन भाषांतरित टोके कधीही बोलू शकणार नाहीत असा निष्कर्षही तुम्ही काढू शकत नाही; रिले बॅकअप असलेला समर्थित स्टॅक अस्तित्वात आहे कारण ते बऱ्याचदा बोलू शकतात। उपलब्धता महत्त्वाची की थेटपणा, हे ठरवा आणि मग अनुकूल परिस्थिती गृहीत धरण्याऐवजी तैनातीने प्रत्यक्षात कोणता मार्ग निवडला ते तपासा।
ब्रोकर नेटवर्कपेक्षा अरुंद आहे
जेव्हा गरज एक ॲप्लिकेशन असते, तेव्हा ॲप ब्रोकर किंवा वर्कस्टेशनने सुरू केलेले उलटे कनेक्शन हे सर्वात लहान उत्तर असू शकते। वर्कस्टेशन बाहेर ब्रोकरकडे डायल करते, ब्रोकर दूरच्या वापरकर्त्याची प्रमाणिती करते, आणि फक्त तेच ॲप्लिकेशन सत्र वाहून नेले जाते। वर्कस्टेशनच्या सबनेटपर्यंत कोणताही मार्ग तयार होत नाही, त्यामुळे दूरच्या सत्राची तडजोड शेजारील प्रत्येक उपकरणापर्यंत मार्ग वारसाहक्काने मिळवत नाही।
या अरुंदपणाची किंमत आहे: प्रत्येक अतिरिक्त ॲप्लिकेशनला स्वतःचे एकत्रीकरण लागते, आणि ॲप्लिकेशन स्थानिक नेटवर्कबद्दल जे गृहीत धरते, जसे की जवळच्या सर्व्हरवर उघडलेला फाइल शेअर, ते पोहोचण्यायोग्य नसू शकते। ब्रोकर धोरण आणि नोंदणी एकाच ठिकाणी केंद्रित करतात, जे ते ठिकाण बिघाड होईपर्यंत उपयुक्त असते।
विश्वासाच्या सीमा तुलना करा, मग मार्ग तपासा
टनेल संपवणारा हब आपण राउट करत असलेली रहदारी वाचू शकतो। ॲप्लिकेशन टोकापासून टोकापर्यंत गुप्तलेखन करते तेव्हा रिले स्वतंत्रपणे संरक्षित देवाणघेवाण वाहू शकतो, आणि ब्रोकर सहसा आपण सादर करत असलेले सत्र संपवतो। दोन्ही गुप्तलेखित आहेत म्हणून दोन रचना समान आहेत असे ठरवण्यापूर्वी संरक्षण प्रत्यक्षात कुठे संपते ते निश्चित करा।
मग वर्कस्टेशन बाहेर प्रत्यक्षात कुठपर्यंत पोहोचते ते तपासा, कारण वरील प्रत्येक रचना त्यावर अवलंबून आहे। हे वर्कस्टेशनवर चालवा, आणि तुम्ही वापरणार असलेले होस्टनाव बदला।
ss -lntup
nc -vz hub.example.com 443
curl -sS -o /dev/null -w "%{http_code}\n" https://hub.example.comअनुमत ओळखीखाली इच्छित दूरची क्रिया यशस्वी झाल्यावर, अनुमती नसलेली ओळख नाकारल्यावर, आणि थेट किंवा रिले मार्ग उपलब्ध नसतानाचे वर्तन माहीत व नोंदलेले असल्यावरच रचना स्वीकारा। पुन्हा जोडणी आणि वर्कस्टेशनचा नेहमीचा स्टार्टअप संदर्भ समाविष्ट करा, कारण कार्यालयात LAN वरून सुरू झालेले सत्र दूरच्या प्रवेशावर अवलंबून असलेले काहीही तपासत नाही।