पोर्ट फर्वार्डिङ बिना 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 मार्फत सुरु भएको सत्रले टाढाको पहुँच निर्भर हुने केही पनि परीक्षण गर्दैन।