Ping จากเกตเวย์ IPsec ใช้อีกแอดเดรสต้นทางหนึ่ง

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

สามคำถามต่างกันที่ ping ตอบได้

คำถามแรกคือปลายทางฝั่งไกลเข้าถึงได้จากโฮสต์นี้หรือไม่ คำถามที่สองคือ selector ของ tunnel หรือนโยบายที่อิงเส้นทางยอมรับทราฟฟิกจากต้นทางหนึ่งหรือไม่ คำถามที่สามคือทราฟฟิกที่ส่งต่อจาก workload หลังเกตเวย์ทำงานได้ตลอดเส้นทางหรือไม่ คำสั่งเดียวตอบทั้งสามไม่ได้ และแอดเดรสต้นทางคือสิ่งที่แยกทั้งสามออกจากกัน

เลือกคำถามก่อน ไม่เช่นนั้น ping ที่ล้มเหลวจะกลายเป็นหลักฐานให้กับทฤษฎีที่คุณมีอยู่แล้ว

ทำไมเกตเวย์จึงเลือกแอดเดรสที่คุณไม่ได้คาดไว้

เมื่อคุณ ping ไปยังปลายทาง stack ในเครื่องจะเลือกต้นทางจากเส้นทางที่ตรงกับปลายทางนั้น บน tunnel ที่อิงเส้นทาง อาจเป็น แอดเดรสลิงก์ของอินเทอร์เฟซ tunnel ซึ่งในการออกแบบไซต์หลายแบบเป็นคู่ 169.254.x.x ที่เลือกไว้สำหรับ hop แบบจุดต่อจุด แอดเดรสเหล่านั้นมีอยู่เพื่อให้ลิงก์ทำงาน และไม่ได้ถูกประกาศเป็นเครือข่ายต้นทางของแอปพลิเคชันที่ฝั่งไกล

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

เลือกต้นทางอย่างตั้งใจ

บนเกตเวย์ Linux ที่ควบคุมได้ เลือกต้นทางที่กำหนดไว้ในเครื่องแล้ว: ping -c 4 -I 10.30.0.1 10.40.0.20 แอดเดรสตรงนี้เป็นตัวอย่าง จึงให้แทนที่ด้วยแอดเดรสภายในจริงของเกตเวย์และปลายทางไกลจริง และยืนยันว่าต้นทางที่คุณเลือกเป็นของอุปกรณ์นี้และได้รับอนุญาตตามนโยบายของไซต์

อย่ายืมแอดเดรสของ workload มาใช้ทดสอบ การแอบอ้างเป็นโฮสต์ที่ไม่ได้กำหนดให้เกตเวย์สร้างผลลัพธ์ที่ไม่มีใครทำซ้ำได้ และบน stack บางตัวมันล้มเหลวในลักษณะที่ดูเหมือน tunnel ผิดปกติ

อ่านเส้นทางขากลับ ไม่ใช่แค่คำขอ

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

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

จากนั้นทดสอบ workload

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

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

อย่าเพิ่มเส้นทางแบบเหมารวมสำหรับ 169.254.0.0/16 เพียงเพื่อให้ได้คำตอบวินิจฉัยข้อเดียว เพราะนั่นแลกการทดสอบที่ทำให้เข้าใจผิดกับการตัดสินใจเรื่องเส้นทางถาวร และคนถัดไปจะรับช่วงต่อโดยไม่มีบริบท