निवृत्तीचे तिकीट उघडण्याच्या दिवशीही तुमचा क्लायंट जोडतो. ॲपमध्ये एक प्रोफाइल बसलेले असते, ते वाटाघाटी करते, आणि काहीही बदलले नसल्यासारखे बोगदे वर येते. सेवा कशी बांधली त्याच्या उलट दिशेने काम करण्याचा हा क्षण आहे: क्लायंट यादीपासून सुरुवात करा, बाहेर श्रोत्यापर्यंत जा, नंतर फायरवॉलपर्यंत, आणि त्या सर्वांपेक्षा जास्त जगणाऱ्या क्रेडेन्शियल्सने संपवा. VM बंद करणे हे पहिले नाही तर शेवटचे पाऊल आहे. हे मार्गदर्शन गृहीत धरते की तुमच्याकडे होस्टवर कन्सोल प्रवेश आणि क्लायंट नोंदी तसेच DNS संपादित करण्याचा अधिकार आहे.

आधी क्लायंट यादीतून जा

तुमची प्रोफाइल्स वितरित करणारे जे काही असेल ते उघडा आणि सर्व्हरला स्पर्श करण्यापूर्वी यादी वाचा. प्रत्येक नोंद अशा उपकरणाची आहे ज्याला वाटते की त्याला प्रवेश आहे: फोन, लॅपटॉप, शाखा राउटर, दररात्री सिंक होणारा कंटेनर. ती यादी तिकिटात निर्यात करा, कारण होस्ट गेल्यावर कोण जोडलेला होता हे सांगणारा wg show राहणार नाही.

प्रत्येक उपकरणाला बदली अंतिम बिंदू, आता आवश्यक नाही, किंवा अज्ञात असे वर्गीकृत करा. अज्ञातांची टोपली महत्त्वाची आहे, कारण महिन्यांनंतर कोणीतरी ड्रॉवरमध्ये सापडणारी आणि वापरून पाहणारी प्रोफाइल्स तीच असतात. प्रवेश विनंत्यांसाठी वापरल्या जाणाऱ्या त्याच चॅनेलवर सूचना पाठवा, आणि जुना अंतिम बिंदू कधी उत्तर देणे थांबवेल ती तारीख त्यात टाका.

ओळख रद्द करा, फक्त फाइल नाही

दोन वेगवेगळ्या क्रिया दोन्हींना रद्दीकरण म्हणतात. WireGuard वर, पीअर फक्त त्याच्या सार्वजनिक कीने अधिकृत होतो, जी AllowedIPs नोंदीसह पीअर विभागात दिसते, म्हणून लॅपटॉपवरून कॉन्फिग फाइल हटवल्याने सर्व्हरवर काहीही बदलत नाही. ठेवलेल्या पीअर्सना पाडल्याशिवाय पीअर ब्लॉक काढा आणि फाइल पुन्हा लागू करा, जसे wg(8) मॅन्युअल सांगते:

wg show
wg set wg0 peer <CLIENT_PUBLIC_KEY> remove
wg syncconf wg0 <(wg-quick strip wg0)

wg syncconf हा देखभाल विंडो वाचवणारा भाग आहे. तो फाइलमधून इंटरफेस तिथेच पुन्हा बांधतो, त्यामुळे एक पीअर काढल्याने बाकी सर्व वापरत असलेला बोगदा तुटत नाही. एका पीअरऐवजी संपूर्ण होस्ट निवृत्त करत असल्यास क्रम अजूनही महत्त्वाचा आहे, कारण त्या किल्ल्यांवर इतरत्र विश्वास ठेवला जाऊ शकतो.

X.509 सेटअपमध्ये रद्द करण्याचे पाऊल फाइल नाही तर प्रमाणपत्र आहे: openssl ca -revoke client.crt आणि नंतर openssl ca -gencrl -out crl.pem. त्याचा परिणाम फक्त तिथे होतो जिथे सत्यापनकर्ता ते वाचतो, म्हणजे OpenVPN सर्व्हर ज्यात crl-verify कॉन्फिगर केलेले आहे आणि नंतर पुन्हा लोड केलेले आहे. हा गेटवे त्या CA चा एकमेव वापरकर्ता असेल, तर तो मरेल त्या दिवशी CRL चे महत्त्व संपते; तीच CA दुसऱ्या गेटवेसाठी सही करत असेल, तर तुम्ही कधीही रद्द न केलेले प्रमाणपत्र तिथे काम करत राहते.

खाती ही तिसरी स्थिती आणि सर्वात जास्त वगळली जाणारी स्थिती आहे. जेव्हा गेटवे RADIUS, LDAP किंवा होस्टेड ओळख पुरवठादाराविरुद्ध प्रमाणित करत होता, तेव्हा खाते VPN बाहेर राहते. ते डिरेक्टरीमध्ये अक्षम करा. सर्व्हरवरील वापरकर्ता स्टॅन्झा हटवल्याने वैध क्रेडेन्शियल राहते, जे बदली अंतिम बिंदू त्याच डिरेक्टरीकडे निर्देश करेल त्या क्षणी स्वीकारेल.

श्रोते आणि त्यांच्यापर्यंतचे मार्ग बंद करा

सेवा पुन्हा सुरू होण्यात टिकेल अशा पद्धतीने थांबवा, नंतर युनिट स्थितीऐवजी सॉकेट यादीने पुष्टी करा. systemctl disable --now wg-quick@wg0 इंटरफेस थांबवते आणि wg-quick ने जोडलेले मार्ग व नियम काढते; systemctl disable --now openvpn-server@server टेम्पलेट OpenVPN इन्स्टन्ससाठी तेच करते. दोन्हींपैकी कोणत्याही नंतर ss -lunp आणि ss -ltnp चालवा. जुन्या पोर्टसाठी रिकामा निकाल हाच एकमेव पुरावा आहे जो मोजला जातो.

wg-quick ने जे जोडले ते wg-quick काढते. तुम्ही हाताने जे जोडले ते राहते: कायमचा NAT नियम, फायरवॉल परवानगी, राउटर पोर्ट-फॉरवर्ड, क्लाउड सुरक्षा-गट इनग्रेस नियम, लोड-बॅलन्सर श्रोता. हे स्पष्टपणे काढावे लागतात, आणि DNS नोंदही, म्हणजे A, AAAA आणि नावाकडे निर्देश करणारा कोणताही CNAME. मृत होस्टकडे रिझोल्व्ह होणारे नाव न-रिझोल्व्ह होणाऱ्या नावापेक्षा वेगळ्या पद्धतीने अयशस्वी होते, आणि तो फरक कोणालातरी एक दुपारचा खर्च करेल.

तुम्ही विसरता ती प्रत म्हणजे क्लोन. बॅकअपमधून पुनर्संचयित केलेला स्नॅपशॉट किंवा VM अजूनही होस्ट की आणि जुनी पीअर यादी धरून ठेवतो, आणि काहीही त्याला त्याच पत्त्यावर परत आणले, तर क्लायंट्स निवृत्त मानलेल्या सेवेशी पुन्हा जोडले जातात. बॅकअप संचाला निवृत्त सेवेचा म्हणून लेबल लावा आणि स्वयंचलित पुनर्संचयित मार्गांबाहेर ठेवा.

जुनी अंतिम बिंदूकडे अजूनही निर्देश करणाऱ्याचा पाठलाग करा

कॅशे केलेली प्रोफाइल्स DNS पेक्षा जास्त जगतात. संख्यात्मक पत्त्यासह जतन केलेले कॉन्फिग नोंद गेल्यानंतरही डायल करत राहते, आणि सदैव सुरू असलेला क्लायंट प्रत्येक नेटवर्क बदलावर पुन्हा प्रयत्न करतो. तो प्रवेश नाही तर गोंगाट आहे, कारण श्रोता बंद आहे, पण तुम्ही दोन्हींपैकी कशाकडे पाहत आहात हे जाणून घेणे तिकिटाला कसे उत्तर द्यावे हे ठरवते.

नंतर कोणीही VPN अंतर्गत संग्रहित न करणाऱ्या अवलंबित्वांना झाडून काढा: पोर्ट चाचपणार्या अपटाइम तपासण्या, होस्टवरून कॉन्फिग ओढणारी बॅकअप कामे, पीअर नोंदी ढकलण्यासाठी वापरलेली ऑटोमेशन क्रेडेन्शियल्स, फक्त या अंतिम बिंदूसाठी तयार केलेली रिकव्हरी खाती. प्रत्येक स्वतःचे आयुष्य आणि स्वतःचा मालक असलेला प्रवेश मार्ग आहे, म्हणून प्रत्येकाला शांत हटवण्याऐवजी निर्णय मिळतो.

पडताळा, मग लिहून ठेवा

बाहेरून केलेली चाचणी अपेक्षेप्रमाणे अयशस्वी झाल्यावर निवृत्ती पूर्ण होते. तुम्ही नियंत्रित न करणाऱ्या नेटवर्कमधून जुन्या पत्त्या आणि पोर्टला जोडा. फिल्टर झालेला किंवा नाकारलेला निकाल ही यशाची स्थिती आहे. क्लायंट ॲपमध्ये प्रोफाइल बंद न करता काढले आहे आणि कोणतेही व्यवस्थापन प्रोफाइल ते गुपचूप पुन्हा जोडत नाही याची खात्री करा.

नंतर तुम्ही काय केले ते नोंदवा: अंतिम बिंदू, तारीख, रद्द केलेल्या की आणि प्रमाणपत्रे, अक्षम केलेली खाती, बॅकअप कुठे आहेत. पुढे कोणाला जुने कॉन्फिग सापडले तर अंदाज न लावता ते रद्द झाले होते की फक्त हटवले होते हे सांगावे लागेल, आणि तिकिटातील एक छोटा तक्ता ते करतो.

तिकीट बंद करण्यापूर्वी:

  • क्लायंट प्रोफाइल्स काढली किंवा बदलली, अज्ञात उपकरणे निकाली
  • पीअर्स काढले आणि कॉन्फिग पुन्हा लागू केले, किंवा प्रमाणपत्रे रद्द केली आणि CRL प्रकाशित केला
  • डिरेक्टरी खाती अक्षम केली, फक्त स्थानिक फाइल्स हटवल्या नाहीत
  • सेवा अक्षम केली, जुन्या पोर्टवर कोणताही श्रोता राहिला नाही
  • फायरवॉल, पोर्ट फॉरवर्ड, सुरक्षा गट आणि DNS नोंदी काढल्या
  • बॅकअपना लेबल लावले, स्नॅपशॉट पुनर्संचयित मार्गांतून वगळला
  • मॉनिटरिंग आणि ऑटोमेशन क्रेडेन्शियल्स निवृत्त

बदली स्वतंत्रपणे पडताळा, कधीही जुने प्रोफाइल नसलेल्या क्लायंटकडून. तीच एक चाचणी सांगते की तुम्ही सेवा निवृत्त केली की फक्त समस्येचे नाव बदलले.

संबंधित लेख