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 सुरुङ-विकल्प कागजात रनबुकको छेउमा राख्नुहोस्।

सम्बन्धित लेखहरू