प्रत्येक OpenVPN नोडवर एकच सेवा IP: ती काय करत नाही
प्रत्येक नोडवर खाजगी /32 राखून ठेवा जेणेकरून ग्राहक आपण निवडलेल्या सर्व्हरपर्यंत पोहोचेल. तो पत्ता बिघाडाच्या वेळी हस्तांतरित होत नाही, सत्रे हलवत नाही आणि निरोगी नोड निवडत नाही.
ग्राहक अनेक OpenVPN सर्व्हरपैकी एकाशी जोडतो आणि नंतर त्याला त्या नोडवर चालणारी छोटी सेवा हवी असते: स्थिती पृष्ठ, मेट्रिक्स एंडपॉइंट, बॅकअप एजंट. प्रत्येक नोडला तोच खाजगी सेवा पत्ता दिल्यास ग्राहकाची संरचना कोणत्या सर्व्हरवर उतरला याच्याशी निगडित न राहता एकसारखी राहते. ती सोय खरी आहे, आणि तिचा अर्थ जास्त लावणेही सोपे आहे: सामायिक पत्ता तुम्ही कोणत्या नोडपर्यंत पोहोचलात हे सांगतो, काहीतरी जास्त आहे हे नाही.
प्रत्येक नोडवर तोच पत्ता का चालतो
प्रत्येक नोड पत्ता स्थानिकरित्या धारण करतो आणि त्यासाठी उत्तर देतो, म्हणून आपल्या सध्याच्या बोगद्यातून त्याला पोहोचणारा ग्राहक त्या बोगद्याच्या दुसऱ्या टोकावर सेवा मिळवतो. नोड्समध्ये काहीही समन्वयित होत नाही, आणि एका नोडवरून दुसऱ्याकडे कोणताही रहदारी जात नाही.
पत्ता हा स्थानिक लेबल आहे, प्रत केलेला नाही तर पुनरावृत्त. प्रत्येक नोड फक्त स्वतःसाठी उत्तर देतो, आणि त्यांच्यापैकी कोणीही दुसऱ्या नोडच्या वतीने पत्त्यासाठी रहदारी पुढे पाठवत नाही. हेच एक ग्राहक संरचना वैध ठेवते, तर सर्व्हर स्वतंत्र राहतात. याच कारणामुळे संरचनेला नोड्समध्ये कोणत्याही समन्वयाची गरज नसते.
म्हणूनच तीच संरचना त्यांच्यातील राउटिंग प्रोटोकॉलशिवाय प्रत्येक सर्व्हरवर चालते. म्हणूनच संरचना आरोग्याबद्दल काहीही सांगत नाही: पत्ता होस्टशी बांधलेला असल्याने, सेवा उपयुक्त आहे की नाही याशी नाही, तो आजारी नोडवरही निरोगी नोडवर जसाच्या तसाच असतो.
ती बोगद्याला नाही, लूपबॅकला द्या
पत्ता लूपबॅक इंटरफेसवर ठेवल्यास तो कोणत्याही बोगदा उपकरणाच्या आयुष्यापासून वेगळा होतो, म्हणून पुन्हा जोडणे किंवा संरचना पुन्हा लोड करणे तो काढत नाही. होस्ट असेपर्यंत पत्ता असतो.
lo वरचा पत्ता फिल्टर नाही. सेवेला तरीही त्यावर ऐकावे लागते, आणि होस्टचा फायरवॉल तरीही खरा येणारा मार्ग मूल्यांकन करतो, जो बोगदा इंटरफेसवर येतो. लूपबॅक म्हणजे फक्त स्थानिक असे गृहीत धरणारे शेवटी एकतर कायदेशीर ग्राहकांना अडवतात किंवा आपली इच्छा नसलेले काही उघड करतात.
नियुक्ती hook मधून पुन्हा जोडण्याऐवजी होस्टच्या नेटवर्क संरचनेद्वारे टिकाऊ करा. ज्या नोडवर बोगदा उभा राहिला नाही तिथे सेटअप hook चालत नाही, आणि सेवा पत्ता बोगद्याच्या हालचालींवर अवलंबून नसावा. पत्ता तुमचे वितरण व्यवस्थापित करते त्या इंटरफेस संरचनेत ठेवा, नंतर एकदा रीबूट करा आणि तो तपासा. नंतरच्या संरचना बदलाला टिकणारी एकमेव चाचणी रीबूट आहे.
ip address show dev lo | grep 10.250.0.1
ip address add 10.250.0.1/32 dev loएक मार्ग ढकला आणि एकच गंतव्य अभिप्रेत करा
ग्राहकाला पत्त्यासाठी होस्ट मार्ग हवा, जो तो ज्या सर्व्हरशी जोडतो तो देतो. प्रत्येक सर्व्हर तेच गंतव्य देत असल्याने, ग्राहक सरकला तरी प्रोफाइल बदलत नाही.
सेवेला दोष देण्यापूर्वी ग्राहकाने काय स्थापित केले ते तपासा.
ip route get 10.250.0.1HTTP सेवेसाठी पत्त्याला नाव द्या आणि त्या नावासाठी प्रमाणपत्र द्या. सामायिक IP ही ओळख नाही, आणि ती TLS पडताळणी काढत नाही, एक खाजगी की प्रत्येक नोडवर नकलणे योग्यही ठरवत नाही. सामायिक पत्त्यावर रिझॉल्व्ह होणारे नाव प्रमाणपत्राची कथा सामान्य ठेवते आणि गरज असल्यास नोडनिहाय ओळख ठेवू देते.
सामायिक पत्ता काय करू शकत नाही
ती बिघाडाच्या वेळी हस्तांतरण देत नाही. निवडलेला नोड मरण पावल्यास पत्ताही त्याच्याबरोबर मरतो, आणि ग्राहकाला दुसरीकडे पुन्हा जोडावे लागते.
ती जिवंत TCP सत्र स्थलांतरित करत नाही, कारण नवीन जोडणी जुन्याबद्दल काहीही न जाणणाऱ्या दुसऱ्या होस्टवर संपते.
ती निरोगी नोड निवडत नाही, भार संतुलित करत नाही आणि नोड्समध्ये माहिती समक्रमित करत नाही. यातील प्रत्येक स्वतःच्या बिघाड पद्धती असलेली वेगळी यंत्रणा आहे, आणि पत्ता-युक्ती त्यांना झाकते असे दाखवणे हाच सोप्या संरचनेला लवचिकतेची नालायक प्रतिष्ठा मिळवून देणारा मार्ग आहे. एकाच वेळी दोन बोगदे सक्रिय असल्यास गंतव्याचा अर्थ संदिग्ध होतो, म्हणून एकच सक्रिय बोगदा हे गृहीत स्पष्ट ठेवा.
सेवेची ओळख नावासोबत ठेवा
पत्त्याचा अर्थ लिहा: तो ग्राहक सध्या ज्या नोडशी जोडलेला आहे त्या नोडवरील सेवेपर्यंत पोहोचतो. ते एक वाक्य हा नमुना आकर्षित करणारे बहुतेक गैरसमज टाळते.
मग भाग एकत्र दस्तऐवजीकरण करा: पत्ता, तो ज्या इंटरफेसवर राहतो तो इंटरफेस, सर्व्हर ढकलणारा मार्ग, आणि सेवा सादर करते ते नाव व प्रमाणपत्र. भविष्यातील वाचक तपासू शकेल अशा चार छोट्या तथ्यांची यादी, तो ती तपासेल त्या क्रमाने.
गरज नोड-स्थानिक सेवेसाठी स्थिर गंतव्य असेल, तर हा नमुना लागू पडतो आणि जवळपास काहीही खर्च करत नाही.
गरज उपलब्धता असेल, तर एक स्तर वर जा: लोड बॅलन्सर, आरोग्य तपासण्यांसह सेवा नाव, किंवा नोड कसा बदलायचा हे आधीच माहीत असलेली ऑर्केस्ट्रेशन प्रणाली.
हे लवकर ठरवल्यास सामायिक पत्ता जो आहे तोच, एक सोयीचे लेबल, राहतो, आणि कधीही रचना न केलेल्या कामाची शांत अपेक्षा ठेवणारा घटक बनत नाही.