การหมุนเวียน 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 ไว้ข้างรันบุ๊ก