तुमच्या व्यवस्थापित VPN चा इंटरनेट एग्झिट प्रत्यक्षात कुठून बाहेर पडतो
«इंटरनेट समाविष्ट» हे सार्वजनिक रहदारी कुठून बाहेर पडते, ती कोण फिल्टर करते किंवा बिघाडानंतर काय टिकते याबद्दल काहीही सांगत नाही। मार्गाचा मागोवा घ्या, आणि नंतर दोन्ही बिघाडाच्या प्रकरणांची नोंद करा।
तो रहदारी प्रदात्याच्या नेटवर्कमधून कुठून बाहेर पडतो हे प्रस्ताव दाखवेपर्यंत, शाखेची सार्वजनिक रहदारी कोण फिल्टर करते हे तुम्ही सांगू शकत नाही। व्यवस्थापित VPN मध्ये समाविष्ट केलेला इंटरनेट प्रवेश ही दुसरी सेवा आहे, जी स्वतःचे गेटवे, स्वतःचे पत्ता भाषांतर आणि स्वतःची एस्कलेशन रांग असलेल्या मार्गावरून जाते। बहुतेक करार खाजगी बाजू तपशीलवार वर्णन करतात आणि सार्वजनिक बाजू एका वाक्यावर सोडतात। खालील तपासण्या त्या वाक्याचे असे आकृतीत रूपांतर करतात जिचे तुम्ही समर्थन करू शकता।
प्रत्येक साइटसाठी एक सार्वजनिक गंतव्यस्थानाचा मागोवा घ्या
शाखेचा एक होस्ट निवडा आणि एका सार्वजनिक गंतव्यस्थानाचा मागोवा घ्या, प्रदात्याचा शेवटचा पत्ता आणि इंटरनेटचा पहिला पत्ता नोंदवा। त्या दोन पत्त्यांमधली उडी म्हणजे एग्झिट, आणि ती बहुतेक वेळा पॅकेट पाठवणाऱ्या साइटजवळही नसते। संक्रमण करणारे उपकरण चिन्हांकित करा, कारण काय बाहेर जाईल हे ठरवणारा फिल्टर त्याच उपकरणात असतो। दुसऱ्या साइटवरून तोच मागोवा पुन्हा घ्या आणि एग्झिट पत्त्यांची तुलना करा, कारण देयकावर सारखी दिसणारी दोन शाखा वेगवेगळ्या शहरांतील वेगवेगळ्या गेटवेमधून बाहेर पडू शकतात।
गंतव्यस्थान प्रत्यक्षात जो स्रोत पत्ता पाहते तोही नोंदवा, कारण भाषांतर तुम्ही कधीही न काढलेल्या उडीवर होऊ शकते। दिसलेली उत्तरे काढलेल्या उत्तरांच्या शेजारी लिहा, आणि त्यांच्यातील अंतर म्हणजे पहिली घटना येथून येईल ते ठिकाण। ठराविक साइटसाठी एग्झिट पत्ता देऊ न शकणाऱ्या प्रदात्याच्या अभियंत्याने तुम्हाला रचनेबद्दल आधीच उपयुक्त काहीतरी सांगितले आहे।
तीन एग्झिट व्यवस्था आणि प्रत्येक काय केंद्रित करते
तुम्ही स्वतः चालवता तो केंद्रीय एग्झिट सार्वजनिक रहदारी तुमच्या स्वतःच्या गेटवेवर ओढतो, ज्यामुळे फिल्टरिंग धोरण आणि लॉग मिळतात, पण सर्व साइटींचा भार एकाच मार्गावर केंद्रित होतो। प्रदात्याने चालवलेला एग्झिट धोरण आणि लॉग कराराच्या सीमेपलीकडे सरकवतो, ज्यामुळे कामकाज सोपे होते आणि त्याच हालचालीत तुमची दृश्यमानता जाते। प्रत्येक साइटवरील एग्झिट सार्वजनिक रहदारी स्थानिक ठेवतो आणि एकसमान राहिल्या पाहिजेत अशा धोरण पृष्ठभागांची संख्या वाढवतो।
| Arrangement | Blast radius of one failure | Address a partner allowlists |
|---|---|---|
| Central exit you operate | Every site, through one circuit and one team | Your own exit pool |
| Provider-run exit | Their shared gateway and its change window | Their NAT pool, often shared |
| Exit at each site | One branch, one local device | Each site's local address |
यादी मेनू म्हणून पाहण्यापूर्वी प्रदाता तीनपैकी कोणती सेवा प्रत्यक्षात देतो ते विचारा, आणि साइट नवीन मार्गाशिवाय त्यांच्यात जाऊ शकते का तेही विचारा। स्थलांतराचे उत्तर करारातील गोष्ट व केवळ तांत्रिक गोष्ट वेगळी करते। स्रोत भाषांतराची मालकी कोणाकडे आहे तेही नोंदवा, कारण भागीदाराने परवानगी यादीत काय घालायचे हे त्यावर ठरते। सामायिक गेटवे म्हणजे सामायिक क्षमता आणि कधीकधी सामायिक प्रतिष्ठाही, ज्यामुळे भागीदार तुमच्या पत्त्यांशी कसे वागतात ते बदलते। क्षमताही स्वतःच्या प्रश्नाला पात्र आहे, कारण सामायिक गेटवे त्याच क्षणी इतर ग्राहकांना सेवा देत असतो।
फिल्टरिंग, भाषांतर आणि एन्क्रिप्शनचे मालक वेगवेगळे आहेत
मार्ग पोहोच स्थापित करतो आणि तपासणीबद्दल काहीही सांगत नाही, म्हणून दोन्हींना वेगवेगळ्या मालकांसह वेगवेगळे प्रश्न माना। प्रत्येक जाहीर केलेल्या डीफॉल्ट मार्गासाठी फिल्टर करणारे उपकरण, प्रमाणीकरण करणारे उपकरण, भाषांतर करणारे उपकरण आणि तपासणी करणारे उपकरण नावाने सांगा, नंतर प्रत्येकाचे व्यवस्थापन कोण करते ते सांगा। प्रदात्याचे मार्ग विभाजन एन्क्रिप्शन कुठे संपते हे सांगत नाही, आणि खाजगी सेवा एका सीमेवर आपली बोगदा संपवू शकते तर सार्वजनिक एग्झिट दुसऱ्या सीमेवर संपते। भाषांतर प्रदात्याच्या काठावर, सामायिक गेटवेवर की तुमच्या स्वतःच्या एग्झिटवर होते, आणि सत्र नोंदी आहेत का व किती काळ ठेवल्या जातात, ते विचारा। उत्तरांमधील मालक मोजा, कारण चार कामांसाठी एकच पक्ष नामनिर्देशित करणारा करार सहसा त्यातील तिघांना कागदपत्रांशिवाय ठेवतो।
एक रुंद डीफॉल्ट मार्ग खाजगी राउटिंग संदर्भात आयात केलेला त्याच तपासणीला पात्र आहे, कारण आयात ही निरुपद्रवी सोय नसून जाणीवपूर्वक केलेला करार आहे। RFC 4364 चा कलम 11 BGP/MPLS VPN साठी अनेक इंटरनेट प्रवेश व्यवस्थांमधून जातो आणि VPN संदर्भ व प्रदात्याच्या डीफॉल्ट फॉर्वर्डिंग संदर्भामधील मार्ग देवाणघेवाणीला नेमका तोच प्रकारचा करार मानतो। सार्वजनिक रहदारी अपघाताने खाजगी मार्ग घेण्यापासून काय थांबवते ते विचारा, आणि उत्तर स्लाइडमध्ये नव्हे तर मार्ग धोरणाच्या शेजारी घ्या।
सही करण्यापूर्वी मान्य करावयाची दोन बिघाडाची प्रकरणे
करारात दोन चाचण्या लिहा: इंटरनेट एग्झिट गमावणे, आणि एक खाजगी जोड गमावणे। प्रत्येकासाठी आंतरिक संसाधने, स्थानिक इंटरनेट सेवा आणि ज्या व्यवस्थापन मार्गांनी कार्यरत राहिले पाहिजे त्यांची यादी करा। मग जो बॅकअप मार्ग अडवलेलाच राहिला पाहिजे त्याची यादी करा, कारण केंद्रीय नियंत्रणांभोवतीचा मार्ग स्वच्छ खंडापेक्षा वाईट आहे। दोन्ही चाचण्या प्रदात्याला द्या आणि शोध व सूचना यासह त्यांचा अपेक्षित निकाल लेखी मागा।
तीच तपासणी एका प्रायोगिक साइटवरून चालवा आणि त्या लेखी उत्तराशी त्यांची तुलना करा। जिथे दोन्ही जुळत नाहीत, तिथे करार तुम्ही खरेदी केलेल्या नेटवर्कपेक्षा वेगळ्या नेटवर्कचे वर्णन करत आहे। दोन आदेश सामान्य प्रकरणे व्यापतात: एक सार्वजनिक गंतव्यस्थान घेत असलेला मार्ग दाखवतो, दुसरा ते जो पत्ता पाहते तो दाखवतो।
traceroute -n 203.0.113.10
curl -s https://example.net/ipउपलब्धतेच्या वचनबद्धता तुम्ही मोजलेल्या विभागाशी जोडा, सेवेच्या नावाशी नाही। स्थानिक मार्ग, प्रदात्याचा बॅकबोन आणि सामायिक गेटवे वेगवेगळी जबाबदारी आणि वेगवेगळी एस्कलेशन पथके घेऊन चालतात। L2VPN, L3VPN आणि MPLS ही अक्षरे फॉर्वर्डिंग यंत्रणा सांगतात, टोकापासून टोकापर्यंतची हमी नाही।
प्रस्तावातील विशेषणांना पुरावे हरवतात
रिडंडंट, सुरक्षित आणि लवचिक अशा शब्दांचा अर्थ रचना नव्हे तर हेतू आहे। त्याऐवजी उपकरणांची यादी, एग्झिटची ठिकाणे, भाषांतराची योजना आणि सूचनेचा मार्ग मागा। जो प्रदाता हे चार गोष्टी देऊ शकतो त्याच्याकडे रचना आहे; जो देऊ शकत नाही त्याच्याकडे स्लाइड आहे। उत्तरे ईमेल थ्रेडमध्ये नव्हे तर सेवा दस्तऐवजात ठेवा, आणि प्रत्येक करार बदलावर त्यांचा फेरआढावा घ्या।
प्रदाते गेटवे एकत्र केल्याने एग्झिट व्यवस्था शांतपणे सरकतात, म्हणून तीन वर्षांपूर्वीची आकृती ओझे आहे। भागीदाराने अनोळखी स्रोत पत्ता नोंदवला की, तो तुमच्या रचनेतून आला की कोणीही जाहीर न केलेल्या बदलातून, हे काही मिनिटांत सांगता आले पाहिजे। विशेषणे नव्हे, हीच क्षमता पहिल्या खंडानंतर टिकते।