AWS VPN PSK घुमाना: कौन-सी सुरंग गिरती है, और कब

किसी AWS VPN सुरंग की एक प्री-शेयर्ड कुंजी बदलने पर वह सुरंग तब तक गिरी रहती है जब तक दोनों पक्ष सहमत न हों। पहले वैकल्पिक मार्ग सिद्ध करें, फिर एक बार में एक सुरंग घुमाएँ।

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

कुंजी बदलने पर वास्तव में क्या होता है

ModifyVpnTunnelOptions एक सुरंग के विकल्प फिर से लिखता है, जिसकी पहचान उसके बाहरी IP पते से होती है। सुरंग तोड़कर फिर बनाई जाती है, इसलिए IKE और IPsec नई कुंजी के साथ शुरू से बातचीत करते हैं। AWS बताता है कि रुकावट कई मिनट चल सकती है, जो किसी राउटिंग प्रोटोकॉल के लिए उसे नोटिस करने हेतु काफ़ी लंबा है। उसी कनेक्शन की दूसरी सुरंग को यह कॉल नहीं छूता।

कुछ भेजने से पहले जानने लायक दूसरा असर भी है। बदलाव का ऑपरेशन सुरंग विकल्पों का पूरा सेट लेता है, इसलिए जो फ़ील्ड आप छोड़ते हैं वह अपने डिफ़ॉल्ट मान के साथ वापस लिखा जाता है। यदि आपने चरण 1 या चरण 2 की आयु, या डेड पीयर डिटेक्शन सेटिंग्स को समायोजित किया है, तो मौजूदा मान उसी अनुरोध में भेजें या बाद में उन्हें बहाल करने की योजना बनाएँ।

पहले मौजूदा मान पढ़ें, फिर एक फ़ील्ड बदलें। यही क्रम इस काम का पूरा अनुशासन है।

पहले AWS सुरंग को सही साथी से मिलाएँ

कंसोल सुरंगों को क्रम से लेबल करता है, और आपका उपकरण वह लेबल नहीं इस्तेमाल करता। सुरंग को उसके बाहरी IP पते से पहचानें और ग्राहक गेटवे पर साथी खंड से मिलाएँ। स्थानीय कॉन्फ़िगरेशन में सुरंग 1 होना इस बात का सबूत नहीं कि आप उस सुरंग को संपादित कर रहे हैं जिसे AWS सुरंग 1 कहता है।

कनेक्शन से ही शुरू करें, जो दोनों सुरंगों और अभी प्रत्येक के पास मौजूद कुंजी की सूची देता है:

aws ec2 describe-vpn-connections --vpn-connection-ids vpn-0123456789abcdef0 \
  --query "VpnConnections[0].Options.TunnelOptions[].[OutsideIpAddress,PreSharedKey]"

जो कुंजी लौटती है वही अभी इस्तेमाल हो रही है। कुछ भी बदलने से पहले उसकी साथी कॉन्फ़िगरेशन से तुलना करें, क्योंकि पहले से मौजूद असंगति उस सुरंग को समझाती है जो कभी स्थिर नहीं थी।

पहले दूसरी सुरंग को ट्रैफ़िक उठाने दें

एक कनेक्शन में दो सुरंगें यह साबित नहीं करतीं कि आपके उपकरण ने दोनों को कॉन्फ़िगर किया है, दोनों आपके ज़रूरी प्रीफ़िक्स घोषित करती हैं, या उनके बीच ट्रैफ़िक चलता है। वैकल्पिक सुरंग की बातचीत, उसके रूट और दोनों दिशाओं में एक वास्तविक एप्लिकेशन प्रवाह जाँचें। BGP के साथ, जीवित सामीप्य उपयोगी सबूत है पर प्रीफ़िक्स की पुष्टि के बराबर नहीं। स्थिर राउटिंग के साथ, पुष्टि करें कि गेटवे मार्ग कैसे चुनता है और पसंदीदा मार्ग हटने पर क्या करता है।

यदि वैकल्पिक सुरंग कार्यभार नहीं उठा सकती, तो कुंजी छूने से पहले रुकावट निर्धारित करें या वैकल्पिक सुरंग ठीक करें। कंसोल पृष्ठ पर स्थिति बत्ती निर्बाध सेवा का वादा नहीं है।

एक सुरंग घुमाएँ, फिर वास्तविक ट्रैफ़िक से सत्यापित करें

वैकल्पिक मार्ग सिद्ध होने पर क्रम छोटा है। सुरंग का पता, उसका साथी और गैर-गोपनीय सेटिंग्स दर्ज करें, और गेटवे तक एक प्रबंधन मार्ग रखें जो उस सुरंग पर निर्भर न हो जिसे आप तोड़ने वाले हैं।

  1. चुने गए बाहरी पते के लिए ग्राहक गेटवे साथी को अपडेट करें, या बदलाव को ऐसे तैयार करें कि वह API कॉल के कुछ सेकंड बाद लागू हो।
  2. नई कुंजी के साथ मौजूदा आयु और DPD मानों सहित बदलाव कॉल भेजें।
  3. IKE और IPsec के लौटने की प्रतीक्षा करें, फिर रूट और आवश्यक प्रीफ़िक्स की पुष्टि करें।
  4. उस सुरंग से एक प्रतिनिधि एप्लिकेशन प्रवाह भेजें और दोनों दिशाएँ देखें।

जब तक सिरे असहमत हैं और AWS बदलाव लागू कर रहा है, सुरंग अनुपयोगी है, इसलिए साथी अपडेट दोपहर के बाद नहीं, तुरंत बाद आना चाहिए। केवल तब, जब बदली हुई सुरंग वास्तविक ट्रैफ़िक उठाए, दूसरी पर प्रक्रिया दोहराएँ।

यदि पहली सुरंग के बाद रिकवरी या राउटिंग अभी भी अनिश्चित है तो रुकें। आधी-अधूरी चलने वाली दो सुरंगें उस एक से बुरी हैं जिसके बारे में आप जानते हैं कि वह चलती है।

जब रिकवरी अटके, तो IKE पक्ष पढ़ें

दोनों सिरों के पास नई कुंजी होने के बाद भी गिरी रहने वाली सुरंग आमतौर पर नीति की असंगति होती है जिसे घुमाने ने उजागर किया, बनाया नहीं। प्रस्ताव, साथी द्वारा भेजी गई पहचान और ट्रैफ़िक चयनक सभी को AWS पक्ष से सहमत होना चाहिए, और स्थापित सुरंग में टिका हुआ मान नई बातचीत के दौरान फिर भी अस्वीकार हो सकता है। दूसरी बार कुंजी बदलने से पहले बातचीत की स्थिति और उससे जुड़ा संदेश पढ़ें।

aws ec2 describe-vpn-connections --vpn-connection-ids vpn-0123456789abcdef0 \
  --query "VpnConnections[0].VgwTelemetry[].[OutsideIpAddress,Status,StatusMessage]"

यदि बदलाव वापस लेना हो, तो पुरानी कुंजी को केवल इसलिए बहाल न करें कि वह पहले चलती थी। समझौता-ग्रस्त कुंजी को समझौता-ग्रस्त मानें और इसके बजाय बातचीत ठीक करें। दोनों सुरंगों के सत्यापित होने और रहस्य-सूची के अपडेट होने के साथ समाप्त करें ताकि हर साथी दर्ज करे कि उसके पास कौन-सा मान है, और AWS सुरंग-विकल्प दस्तावेज़ीकरण को रनबुक के पास रखें।

संबंधित लेख