ควรเปิดใช้งานบันทึกทันเนลของ AWS VPN บนทันเนลที่ใช้งานอยู่หรือไม่?

การเปิดบันทึกกิจกรรมของทันเนลสำหรับ VPN แบบ Site-to-Site เป็นการเปลี่ยนแปลงเล็ก ๆ ที่อาจทำให้ทันเนลที่มันกำลังวัดอยู่นั้นล่มได้ AWS เตือนว่าการเปิดใช้งานการบันทึกบนทันเนลที่มีอยู่แล้วอาจทำให้ทันเนลหยุดชะงักหลายนาที ดังนั้นคำถามที่น่าสนใจจึงไม่ใช่จะพลิกธงอย่างไร แต่เป็นจะพลิกที่ทันเนลใดและเมื่อใด มีสามเงื่อนไขที่กำหนดลำดับ ได้แก่ ทันเนลอีกฝั่งรับส่งเส้นทางจริงหรือไม่ คุณต้องการเหตุการณ์ของบริการหรือเหตุการณ์ BGP และการเปลี่ยนแปลงทำผ่านคอนโซลหรือผ่าน API ของตัวเลือกทันเนล หากทำผิดพลาดคุณจะจบลงด้วยการหยุดชะงักหรือกลุ่มบันทึกที่เต็มไปด้วยความว่างเปล่า

สามเงื่อนไขที่กำหนดลำดับ

เริ่มจากตัวตนของสิ่งที่คุณกำลังเปลี่ยนแปลง คุณต้องมี ID การเชื่อมต่อ VPN ภูมิภาค และที่อยู่ IP ภายนอกของทันเนลที่เจาะจง เพราะทุกการตั้งค่าบันทึกในฟีเจอร์นี้เป็นรายทันเนล ไม่ใช่รายการเชื่อมต่อ การเปลี่ยนแปลงที่ใช้กับที่อยู่ภายนอกผิดตัวคือการเปลี่ยนทันเนลที่ไม่มีใครกำลังดีบั๊กอยู่

ปลายทางคือกลุ่มบันทึก CloudWatch ในภูมิภาคเดียวกัน พร้อมนโยบายการเก็บรักษาและการเข้าถึงที่คุณต้องการจริง ๆ AWS แนะนำคำนำหน้า /aws/vendedlogs/ สำหรับกลุ่มเหล่านี้เพราะหลีกเลี่ยงขีดจำกัดขนาดนโยบายทรัพยากรที่ชื่อธรรมดาอาจชนได้ ชื่ออย่าง /aws/vendedlogs/vpn/branch-a-activity เป็นเพียงตัวอย่าง สิ่งที่สำคัญคือกลุ่มมีอยู่จริง บทบาทการส่งมอบสามารถเขียนลงไปได้ และทั้งสองอย่างถูกจัดการโดยผู้ที่เป็นเจ้าของการกำหนดค่า VPN ชื่อไม่ได้ให้สิทธิ์ และกลุ่มที่สร้างขึ้นโดยไม่มีนโยบายการส่งมอบจะให้ความเงียบแทนที่จะเป็นข้อผิดพลาด

เงื่อนไขข้อแรก: ทันเนลสำรองที่รับส่งทราฟฟิกจริง

นี่คือเงื่อนไขที่ทีมมักข้ามไป ทันเนลที่กำหนดค่าไว้สองเส้นไม่ใช่หลักฐานว่าแอปพลิเคชันมีเส้นทางสำรองที่ใช้งานได้

ก่อนจะแตะทันเนลหนึ่งเส้น ตรวจสอบให้แน่ใจว่าอีกเส้นรับส่งเส้นทางที่สำคัญอยู่: ตรวจสอบตารางเส้นทางฝั่งเกตเวย์ของลูกค้า และยืนยันว่าแอปพลิเคชันสลับไปใช้ได้จริง หน้าต่างการหยุดชะงักของ AWS นับเป็นนาที ไม่ใช่วินาที และทันเนลที่มีอยู่แค่บนกระดาษจะเปลี่ยนการเปลี่ยนแปลงเพื่อวินิจฉัยให้กลายเป็นการหยุดชะงัก หากเส้นทางสำรองยังพิสูจน์ไม่ได้ ให้วางแผนการเปลี่ยนแปลงอย่างระมัดระวังเท่ากับการเปลี่ยนแปลงเส้นทางอื่น ๆ แทนที่จะถือว่าการบันทึกเป็นเรื่องที่ไม่มีผลกระทบ วัดผลทันเนลที่คุณพยายามอธิบายพฤติกรรม ไม่ใช่เส้นที่เข้าถึงง่ายกว่า

เงื่อนไขข้อสอง: บันทึกกิจกรรมหรือบันทึก BGP

เงื่อนไขนี้กำหนดว่าคุณจะอ่านอะไรได้จริง บันทึกกิจกรรมครอบคลุมเหตุการณ์ของบริการ เช่น การเปลี่ยนสถานะของ IKE และ IPsec และข้อความ DPD ซึ่งเป็นสิ่งที่คุณต้องการเมื่อทันเนลไม่ขึ้นหรือหมุนเวียนคีย์ตลอดเวลา บันทึก BGP เป็นสตรีมแยกที่มีการควบคุมของตัวเอง และตอบคำถามอีกข้อหนึ่งว่าเส้นทางถูกแลกเปลี่ยนและถอนออกตามที่คาดไว้หรือไม่

การเปิดธงกิจกรรมไม่ใช่การขอทุกสตรีมที่บริการสามารถปล่อยออกมาได้ หากสงสัยเรื่องเส้นทาง ให้เปิดทั้งสองอย่าง หากสงสัยการเจรจาเฟส 1 หรือเฟส 2 สตรีมกิจกรรมคือสิ่งที่แสดงให้เห็น

ไม่มีสตรีมใดเป็นการดักจับแพ็กเก็ต และความแตกต่างนี้แก้ปัญหาตั๋วได้มากกว่าที่ควร บันทึกกิจกรรมและ BGP บอกคุณว่าบริการทำอะไรกับทันเนลและเซสชัน ไม่ใช่สิ่งที่แอปพลิเคชันของคุณส่งผ่านเข้าไป การเอื้อมไปหยิบบันทึกทันเนลเพื่อดีบั๊กการหมดเวลาของแอปพลิเคชันเป็นความผิดพลาดเชิงหมวดหมู่ และมักต้องแลกด้วยหน้าต่างหยุดชะงักหนึ่งครั้งก่อนที่ใครจะสังเกตเห็น เลือกคำถามก่อน แล้วจึงเลือกสตรีมที่ตอบคำถามนั้นได้

เงื่อนไขข้อสาม: เปลี่ยนผ่านคอนโซลหรือ API ของตัวเลือกทันเนล

หากมีคนทำการเปลี่ยนแปลงครั้งเดียว เส้นทางผ่านคอนโซลก็ใช้ได้: VPC console, Site-to-Site VPN connections เลือกการเชื่อมต่อ Actions, Modify VPN tunnel options เลือก IP ภายนอก เปิด Tunnel activity log เลือกกลุ่มและรูปแบบเอาต์พุต บันทึกภายในหน้าต่าง หาก VPN ถูกจัดการเป็นโค้ด การคลิกเดียวกันนั้นคือ drift ที่คุณจะกระทบยอดภายหลัง

สำหรับระบบอัตโนมัติ ส่วนบันทึกกิจกรรมของตัวเลือกทันเนลมีรูปแบบตายตัว: LogOptions ที่มี CloudWatchLogOptions พร้อม LogEnabled, LogGroupArn และ LogOutputFormat บล็อกนั้นเป็นชิ้นส่วน ไม่ใช่คำขอ modify-vpn-tunnel-options ยังต้องใช้ ID การเชื่อมต่อและ IP ภายนอกของทันเนล และการตั้งค่าทันเนลที่เหลือต้องถูกรักษาไว้โดยผู้ที่เป็นเจ้าของเทมเพลต การบันทึก BGP ใช้คีย์ของตัวเอง BgpLogEnabled, BgpLogGroupArn และ BgpLogOutputFormat ในโครงสร้างเดียวกัน อ่านการเปลี่ยนแปลงกลับด้วย describe-vpn-connections แทนที่จะเชื่อว่าการเรียกนั้นถูกนำไปใช้แล้ว

สิ่งที่บันทึกบอกคุณได้และบอกไม่ได้

เมื่อทันเนลแรกเสร็จสิ้นและเส้นทางที่ตั้งใจไว้พร้อมใช้งาน ให้ทำลำดับควบคุมเดียวกันซ้ำกับทันเนลที่สองหากคุณต้องการบันทึกของมันด้วย ครั้งละหนึ่งทันเนลคือประเด็นทั้งหมด

บันทึกมาถึงในสตรีมที่ระบุด้วยการเชื่อมต่อและที่อยู่ภายนอกของทันเนล ดังนั้นให้เชื่อมโยงกับตัวตนนั้นแทนที่จะคาดหวังว่าประวัติจะปรากฏย้อนหลัง ไม่มีสิ่งใดก่อนการเปลี่ยนแปลง และการรอไม่ว่าจะนานเท่าใดก็ไม่เติมช่องว่างนั้น หากคุณต้องการเส้นฐาน ให้บันทึกสถานะทันเนลและตารางเส้นทางปัจจุบันก่อนการเปลี่ยนแปลง เพื่อให้มีอะไรให้เปรียบเทียบ

เก็บกลุ่มบันทึก การเก็บรักษา สิทธิ์การส่งมอบ และบล็อกตัวเลือกทันเนลไว้ในสินค้าคงคลังเดียวกับ VPN เอง เพราะมันคือการกำหนดค่าเดียวที่กระจายอยู่สี่ที่ ขั้นตอนของ AWS ในการเปิดบันทึก อธิบายขั้นตอนการทำงานรายทันเนลและคำเตือนการหยุดชะงัก และควรอ่านก่อนการเปลี่ยนแปลงไม่ใช่หลัง จากนั้นตรวจสอบตามลำดับ: ทันเนลกลับมา บันทึกปรากฏในสตรีมที่คาดไว้ และบันทึกตอบคำถามที่ทำให้คุณเปิดตั๋ว หากข้อที่สามล้มเหลว ปัญหาคือการเลือกสตรีม ไม่ใช่การบันทึก