VPN के लिए लीज़्ड लाइन? पहले आवश्यकता का अनुवाद करें

प्रस्ताव कार्यालय के VPN के लिए एक विशिष्ट लीज़्ड लाइन का नाम लेता है, और संख्या बिना किसी व्याख्या के आती है। हस्ताक्षर करने से पहले, उस वाक्य को उन चार आवश्यकताओं में बाँटें जिन्हें वह वास्तव में छिपा रहा है: भौतिक हैंडऑफ़, IP डिलीवरी की व्यवस्था, दोनों दिशाओं में क्षमता, और सर्किट के पीछे की सहायता प्रतिबद्धता। इन्हें उसी क्रम में द्वारों की तरह चलाएँ, क्योंकि हैंडऑफ़ में विफल सर्किट को बड़े बैंडविड्थ आँकड़े से नहीं बचाया जा सकता। फिर जो वितरित हुआ है उसे उससे मिलाएँ जो आपने लिखा था।

आवश्यकता का अनुवाद करें, उत्पाद के नाम का नहीं

IPsec IP परत पर ट्रैफ़िक की रक्षा करता है और ढुलाई आपके द्वारा खरीदे गए सर्किट पर छोड़ देता है। IPsec आर्किटेक्चर बताता है कि सहकर्मियों के बीच ट्रैफ़िक की रक्षा कैसे होती है; यह हैंडऑफ़ के प्रकार, प्रतिबद्ध दरों या मरम्मत विंडो के बारे में कुछ नहीं कहता। वे सेवा अनुबंध के गुण हैं।

यही अंतर वह पूरा कारण है कि सर्किट की आवश्यकता वैध हो सकती है और फिर भी VPN की आवश्यकता न हो। केवल सीरियल इंटरफ़ेस वाले गेटवे को सचमुच सीरियल हैंडऑफ़ चाहिए, और यह प्रोटोकॉल की नहीं बल्कि हार्डवेयर की सीमा है। उपकरण बदल दें और सीमा गायब हो जाती है। हर आवश्यकता को «गेटवे को X चाहिए क्योंकि Y» के रूप में लिखें, और हर उस पंक्ति को अस्वीकार करें जो पूरी नहीं हो सकती।

गति का नाम लेने से पहले हैंडऑफ़ का नाम लें

हैंडऑफ़ सीमांकन बिंदु पर भौतिक और लिंक-परत कनेक्शन है: ताँबे का ईथरनेट, किसी विशेष ट्रांसीवर वाला फ़ाइबर, सीरियल इंटरफ़ेस, या कुछ पुराना जो केवल इसलिए मौजूद है क्योंकि मौजूदा उपकरण में वह है। इसे गलत करना उस तरह महँगा है जैसे बैंडविड्थ कभी नहीं होता, क्योंकि इसका मतलब आमतौर पर दोनों सिरों पर नया हार्डवेयर होता है। गायब ऑप्टिक क्षमता की समस्या नहीं है और कोई अपग्रेड उसे ठीक नहीं करता।

कनेक्टर, गति की बातचीत और यह कि मीडिया कन्वर्टर या राउटर कौन देता है, इसकी पुष्टि करें। फिर पुष्टि करें कि आपकी ज़िम्मेदारी कहाँ खत्म होती है, क्योंकि सीमांकन बिंदु तय करता है कि लिंक के 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 डिलीवरी, क्षमता और सहायता शर्तों में से हर एक की रिकॉर्ड में एक पंक्ति है, और हर पंक्ति के बगल में एक नाम है।