VPN का लागि भाडाको लाइन? पहिले आवश्यकता अनुवाद गर्नुहोस्

प्रस्तावले कार्यालय VPN का लागि एक विशेष भाडाको लाइन उल्लेख गर्छ, र संख्या कुनै पनि व्याख्याविना आउँछ. हस्ताक्षर गर्नु अघि वाक्यलाई यसले वास्तवमै लुकाइरहेका चार आवश्यकतामा विभाजन गर्नुहोस्: भौतिक हस्तान्तरण, IP वितरणको व्यवस्था, दुवै दिशामा क्षमता र सर्किट पछाडिको समर्थन प्रतिबद्धता. तिनीहरूलाई त्यही क्रममा प्रवेशद्वारको रूपमा जाँच्नुहोस्, किनकि हस्तान्तरणमा असफल हुने सर्किटलाई ठूलो ब्यान्डविथको अंकले बचाउन सक्दैन. त्यसपछि वितरित भएको कुरालाई तपाईंले लेखेकोसँग तुलना गर्नुहोस्.

उत्पादनको नाम होइन, आवश्यकता अनुवाद गर्नुहोस्

IPsec ले IP तहमा ट्राफिकको सुरक्षा गर्छ र ढुवानी तपाईंले किन्नुहुने सर्किटमा छोड्छ. IPsec स्थापत्य ले दुई पक्षबीच ट्राफिक कसरी सुरक्षित हुन्छ भन्ने वर्णन गर्छ; हस्तान्तरणको प्रकार, सुनिश्चित दर वा मर्मतको समयसीमाबारे केही भन्दैन. ती सेवा सम्झौताका गुण हुन्.

यही भिन्नता नै सर्किटको आवश्यकता वैध हुँदाहुँदै पनि VPN को आवश्यकता नहुनुको सम्पूर्ण कारण हो. केवल क्रमिक इन्टरफेस भएको गेटवेलाई साँच्चै क्रमिक हस्तान्तरण चाहिन्छ, र त्यो प्रोटोकलको होइन, हार्डवेयरको सीमा हो. उपकरण बदल्नुहोस् र सीमा हराउँछ. प्रत्येक आवश्यकता «गेटवेलाई X चाहिन्छ, किनकि Y» ढाँचामा लेख्नुहोस् र पूरा गर्न नसकिने कुनै पनि लाइन अस्वीकार गर्नुहोस्.

गतिको अघि हस्तान्तरणको नाम राख्नुहोस्

हस्तान्तरण भनेको सीमा बिन्दुमा हुने भौतिक र लिङ्क तहको जडान हो: तामाको Ethernet, विशेष ट्रान्सीभर भएको फाइबर, क्रमिक इन्टरफेस, वा हालको उपकरणमा भएकै कारणले मात्र अस्तित्वमा रहेको पुरानो कुरा. यहाँ गल्ती गर्नु ब्यान्डविथमा कहिल्यै नहुने तरिकाले महँगो हुन्छ, किनकि सामान्यतया दुवै छेउमा नयाँ हार्डवेयर भन्ने अर्थ लाग्छ. हराएको अप्टिक क्षमताको समस्या होइन र कुनै अपग्रेडले त्यसलाई सुधार्दैन.

कनेक्टर, गतिको वार्ता र मिडिया कन्भर्टर वा राउटर कसले आपूर्ति गर्छ भन्ने पुष्टि गर्नुहोस्. त्यसपछि तपाईंको जिम्मेवारी कहाँ सकिन्छ भन्ने पुष्टि गर्नुहोस्, किनकि 03:00 बजे लिङ्क खस्दा कसले के छुन पाउँछ भन्ने सीमा बिन्दुले निर्धारण गर्छ. त्यो सीमा सर्किट पहिचानको छेउमा रहेको अभिलेखमा लेख्नुहोस्. समर्थन कललाई एक घण्टाको हस्तान्तरणको सट्टा पाँच मिनेटको कुराकानी बनाउने एक मात्र लाइन त्यही हो.

ip -br link show
ethtool eth0 | head -20
sudo lshw -class network -short

ठेगाना मात्र होइन, IP वितरण पुष्टि गर्नुहोस्

सेवाले वास्तवमै कुन ठेगाना वा प्रिफिक्स दिन्छ र त्यो स्थिर छ कि भनी सोध्नुहोस्. गतिशील ठेगाना दिने सर्किट साइट-देखि-साइट गेटवेका लागि राम्रो मिल्दैन, किनकि सहकर्मीको कन्फिगरेसनले तपाईंले योजना नगरेको परिवर्तन सहनुपर्छ. प्रिफिक्सको लम्बाइ पनि पुष्टि गर्नुहोस्, किनकि एउटा ठेगाना र रुट गरिएको /29 फरक उत्पादन हुन्.

त्यसपछि तपाईंसम्म पुग्नु अघि केहीले ठेगाना अनुवाद गर्छ कि भनी सोध्नुहोस्. सेवाको अगाडि रहेको आपूर्तिकर्ताको तर्फको NAT वा वाहक-स्तरको NAT ले भित्र आउने सत्रहरू भाँच्छ, त्यसैले टाढाका साइटबाट IPsec स्वीकार गर्ने अपेक्षा गरेको गेटवेसम्म पुग्न सकिँदैन. गतिले क्षतिपूर्ति गर्दैन: तपाईंले नियन्त्रण नगरेको अनुवादक पछाडिको द्रुत लिङ्कले कसैले अगाडि नपठाएको पोर्टमा भित्र आउने जडान स्वीकार गर्न सक्दैन.

राउटर र DNS कसको स्वामित्वमा छ भनी अभिलेख गर्नुहोस्. आपूर्तिकर्ताले राउटर दिन्छ भने तपाईंले त्यसको फर्मवेयर, त्यसको NAT व्यवहार र पूर्वनिर्धारित मार्गबारे त्यसको धारणा उत्तराधिकारमा पाउनुहुन्छ, र पछिको हरेक परिवर्तन टिकटबाट जान्छ. तपाईंको नेटवर्क बाहिरको कसैलाई तपाईं पुग्ने अपेक्षा गर्नुभएको पोर्टमा भित्र आउने जडान प्रयास गर्न लगाउनुहोस्, किनकि अनुवादको कथा प्रमाणित गर्ने त्यही एक मात्र परीक्षण हो.

ip -br addr
ip route get 198.51.100.10
traceroute -n 198.51.100.10

क्षमता कार्यभारबाट, दुवै दिशामा गणना गर्नुहोस्

क्षमता प्रति प्रयोगकर्ता अंकमा होइन, कामको रूपमा वर्णन गर्नुपर्छ. ठूलो मात्रामा फाइल पहुँच, अन्तरक्रियात्मक प्रशासन र रातको ब्याकअपले फरक ट्राफिक ढाँचा बनाउँछ, र तीमध्ये एउटाले मात्र निरन्तर माथि तर्फको थ्रुपुटको चासो राख्छ. प्रति सिट ब्यान्डविथको अंक बिक्रीको सुविधा हो, मोडेल होइन.

दुवै दिशाको अनुमान गर्नुहोस्, इन्क्याप्सुलेसनको थप भार जोड्नुहोस् र ट्राफिक विस्फोटक हो वा निरन्तर भनी टिप्नुहोस्. त्यसपछि सम्झौताको विज्ञापन दर होइन, सुनिश्चित दर जाँच्नुहोस्, किनकि केही सेकेन्डमै सकिने विस्फोट भत्ताले रातको ब्याकअपलाई सहयोग गर्दैन. गेटवेकै सीमाहरू पनि त्यही बजेटमा राख्नुहोस्, किनकि इन्क्रिप्शन प्रशोधन र एकै समयका सत्रको संख्या सर्किटभन्दा धेरै अगाडि सीमा बन्न सक्छ. छिटो लाइनले भरिएको गेटवे सुधार्दैन.

सञ्चालन प्रतिबद्धता निश्चित गर्नुहोस्

उपलब्धता, मर्मत प्रतिक्रिया, उन्नयन मार्ग र मर्मत सूचना मापन विधिको नामसहित लिखित रूपमा हुनुपर्छ. इन्टरनेटको विज्ञापन दरले यीमध्ये कुनै पनि गुण स्थापित गर्दैन, र आउटेज परिभाषित नगरी विश्वसनीयताको वाचा गर्ने मार्केटिङ पृष्ठले पनि गर्दैन. घडी कसरी सुरु हुन्छ सोध्नुहोस्, किनकि आपूर्तिकर्ताकै स्वीकृतिबाट मापन गरिएको प्रतिक्रिया समय तपाईंको निगरानी सूचनाबाट मापन गरिएको अंकसँग उस्तै हुँदैन. ती दुई परिभाषा कसैले झुट नबोलीकन पनि घण्टौं फरक हुन सक्छन्.

समर्थनको सीमा पनि अभिलेख गर्नुहोस्. आपूर्तिकर्ताको जिम्मेवारी तपाईंको आफ्नै राउटरले अन्त्य गर्ने हस्तान्तरण बिन्दुमा सकिन्छ भने, हरेक घटनाको पहिलो घण्टा दोष कसको हो भनी निर्धारण गर्नमै जान्छ, र कुनै SLA घडीले त्यसलाई ढाक्दैन.

सर्किटलाई लिखित सर्तसँग तुलना गरी प्रमाणित गर्नुहोस्

सेवा सञ्चालनमा आएपछि, जडानकर्ताले देखाएका गुण होइन, तपाईंले साँच्चै सम्झौता गरेका गुण मापन गर्नुहोस्. वास्तविक मार्गमा थ्रुपुट, ढिलाइ र हानि नै प्रमाण हो, र तिनीहरू तपाईंले नाम दिन सक्ने समय र स्थानबाट अभिलेख गर्नुपर्छ. मापन हस्तान्तरणको बेला मात्र होइन, व्यस्त घडीमा पनि दोहोर्याउनुहोस्. शान्त दिनको 10:00 बजे गरिएको स्वीकृति परीक्षणले 15:00 बजेको लिङ्कबारे धेरै थोरै बताउँछ.

iperf3 -c speed.example.net -t 30 -P 4
mtr -n --report -c 50 198.51.100.10
curl -sS -o /dev/null -w '%{time_connect} %{time_starttransfer}\n' https://speed.example.net/

नतिजा सम्झौतासँगै राख्नुहोस्, किनकि आधाररेखाविनाको कार्यसम्पादन छलफल धारणाबारेको वादविवाद हो. मापनले प्रतिबद्धता पूरा गरेन भने, प्रमाण ताजा हुँदै र सेवा सम्झौताले दिएको स्वीकृति अवधिभित्रै हुँदै उठाउनुहोस्. अनुरोधमा नाम दिइएको होस्टले TLS ह्यान्डशेक पनि वैध राख्छ, त्यसैले प्रमाणपत्रको चेतावनीलाई असफल सर्किट ठानिँदैन.

अन्तमा, वितरित भएकोसँग चारै प्रवेशद्वार पुनः पढ्नुहोस्. हस्तान्तरण, IP वितरण, क्षमता र समर्थनका सर्तको प्रत्येकको अभिलेखमा एक लाइन छ, र हरेक लाइनको छेउमा नाम छ.