การตรวจสอบต้นทาง/ปลายทางเป็นเพียงประตูบานเดียว ไม่ใช่เส้นทาง VPN ทั้งหมด

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

แยกการทดสอบสองอย่างออกจากกันก่อนจะเปลี่ยนอะไร

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

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

จดเส้นทางไว้ก่อนจะแตะการตั้งค่า

บันทึกคำนำหน้าของไคลเอนต์ อินสแตนซ์หรืออินเทอร์เฟซเครือข่ายที่ส่งต่อ ซับเน็ตเป้าหมาย และเส้นทางตอบกลับ รายการในตารางเส้นทางของ VPC ที่ชี้ไปยังอินสแตนซ์ไม่ได้ตั้งค่าระบบปฏิบัติการของอินสแตนซ์ให้ส่งต่อ และเคอร์เนลของผู้เยี่ยมที่เปิดการส่งต่อไว้ก็ไม่ได้สร้างเส้นทาง VPC ปลายทั้งสองข้างของความสัมพันธ์นั้นต้องมีอยู่ และ มันถูกแก้ไขในที่ต่างกันโดยคนที่มีสิทธิ์เข้าถึงต่างกัน

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

สี่ขอบเขต และการตรวจสอบเป็นเพียงหนึ่งในนั้น

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

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

การแปลเปลี่ยนว่าปลายทางเห็นต้นทางใด

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

หากคุณแปล ให้จำกัดกฎไว้ที่คำนำหน้าของไคลเอนต์และปลายทางที่ตั้งใจ หากคุณรักษาไว้ ให้ยืนยันว่าฝั่งไกลรู้เส้นทางจริง ไม่ใช่สมมติว่ามันจะเรียนรู้เอง

ทดสอบจากไคลเอนต์ต้นฉบับ แล้วเก็บการเปลี่ยนแปลงไว้

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

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