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 वितरण, क्षमता आणि मदतीच्या अटी या प्रत्येकाची नोंदीत एक ओळ आहे आणि प्रत्येक ओळीच्या शेजारी नाव आहे.