VPN S2S บน Azure เชื่อมต่อแล้วแต่ไม่มีทราฟฟิก: อ่านบันทึก IKE

พอร์ทัลแสดงว่าเชื่อมต่อแล้ว ทันเนลมีตัวนับเวลาทำงาน และ trace จากเครื่องเสมือนของคุณตายที่ฮอปที่สอง สถานะการเชื่อมต่ออธิบายการเจรจาของ IKE และ IPsec ไม่ใช่ว่าแพ็กเก็ตเดียวจะรอดผ่านชั้นนโยบายบนฝั่งใดฝั่งหนึ่งหรือไม่ ความผิดพลาดสองอย่างอธิบายตั๋วส่วนใหญ่เหล่านี้ และไม่มีอย่างไหนแก้ได้ด้วยการเปลี่ยนเส้นทางใน Azure ทั้งสองอย่างเขียนอยู่ในบันทึกที่เกตเวย์สร้างขึ้นแล้ว จึงเป็นเหตุผลที่ผมเริ่มจากตรงนั้นไม่ใช่จากตารางเส้นทาง

สิ่งที่ Connected รับรองจริง ๆ

การเชื่อมต่อแบบ site-to-site ที่เชื่อมต่อแล้วหมายความว่า เฟส 1 และเฟส 2 เสร็จสมบูรณ์ และสมาคมความปลอดภัยทำงานอยู่ นี่เป็นข้อความเกี่ยวกับการเจรจา: ทั้งสองฝ่ายตกลงข้อเสนอ แลกกุญแจ และติดตั้งคู่ SA ข้อความนี้ไม่บอกว่าตัวเลือกทราฟฟิกตรงกับซับเน็ตที่คุณคิดว่าถูกป้องกันหรือไม่ และไม่บอกว่าอีกฝ่ายจะกำหนดเส้นทางแพ็กเก็ตไปที่ใดหลังถอดรหัส ทันเนลสามารถทำงานอยู่ได้หลายสัปดาห์ขณะที่ทิ้งทุกโฟลว์ที่น่าสนใจ และนั่นคือรูปแบบที่ทำให้คนสร้างเกตเวย์ที่ดีอยู่แล้วใหม่ทั้งอัน

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

เปิดบันทึกที่ส่งออกก่อนแตะเส้นทาง

ในพอร์ทัล เปิดเกตเวย์เครือข่ายเสมือนและรันการทำงาน VPN troubleshoot บนการเชื่อมต่อ จากนั้นดาวน์โหลดชุดไฟล์ที่มันสร้างและแตกไฟล์ ภายในมีบันทึก IKE พร้อมการแลกเปลี่ยนเฟส 1 และเฟส 2 มีตราเวลาและอ่านได้เป็นข้อความธรรมดา ให้ค้นหาบรรทัด transform แทนการอ่านจากบนลงล่าง เพราะรายการที่น่าสนใจมักอยู่ลึกไปหลายร้อยบรรทัด หากไม่มีสิทธิ์เข้าพอร์ทัล การวินิจฉัยเดียวกันจะปรากฏที่ปลายทางบันทึกของเกตเวย์เมื่อเปิดการตั้งค่าการวินิจฉัยไว้

สองรายการถือคุณค่าไว้เกือบทั้งหมด รายการแรกอ่านได้ประมาณ expected ESP with combined authentication and cipher, received AH รายการที่สองคือข้อผิดพลาด payload ไม่ถูกต้องระหว่างการแลกเปลี่ยน IKE ซึ่งมักหมายถึงฟิลด์ข้อเสนอที่สร้างผิดรูปหรือไม่รองรับ

ทั้งสองอธิบายสิ่งที่อุปกรณ์ฝั่งองค์กรเสนอ ดังนั้นทั้งคู่เป็นการตั้งค่าฝั่ง peer การสร้างฝั่ง Azure ของการเชื่อมต่อใหม่ไม่เปลี่ยนข้อเสนอที่ไฟร์วอลล์ของคุณส่ง และการทำเช่นนั้นก็ยังเป็นชั่วโมงที่เสียเปล่าที่สุดในงานนี้ บน peer ให้ตั้งเฟส 2 เป็น ESP พร้อมการพิสูจน์ตัวตนและการเข้ารหัสแบบรวม แล้วปล่อยให้เจรจาอัลกอริทึม จากนั้นตรวจว่าช่องทำเครื่องหมายของผู้จำหน่ายชื่อคล้าย combined mode เลือกข้อเสนอ AH ไว้ข้างใต้อย่างเงียบ ๆ หรือไม่

ยืนยันพื้นที่แอดเดรสของเครือข่ายเสมือน

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

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

ตรวจสอบคำนำหน้าในทั้งสองทิศทาง

ทรัพยากรเกตเวย์เครือข่ายภายในมีคำนำหน้าขององค์กร และต้องตรงกับซับเน็ตที่อุปกรณ์ปลายทางป้องกันจริง สรุปที่มีแอดเดรสซึ่งอุปกรณ์ทิ้งจะปล่อยบางโฟลว์ผ่านและล้มเหลวในโฟลว์อื่น ซึ่งอ่านได้เหมือนความผิดพลาดในการกำหนดเส้นทางเป็นครั้งคราว ไม่ใช่ความไม่ตรงกันของการกำหนดค่า ตรวจฝั่งไกลด้วย: ปลายหนึ่งระบุ /16 ขณะที่อีกปลายระบุ /24 สามรายการข้างใน — นั่นคือความล้มเหลวบางส่วนแบบคลาสสิก ไม่มีรายการใดเป็นทางการโดยลำพัง ดังนั้นให้เทียบทั้งสองข้างเคียงกันแทนที่จะเชื่อรายการที่คุณมองเห็น

การเปลี่ยนคำนำหน้าไม่ได้รับอัตโนมัติเสมอ ดังนั้นวางแผนบันทึกหรือสร้างออบเจ็กต์การเชื่อมต่อใหม่ แล้วยืนยันว่าคำนำหน้าใหม่ปรากฏทั้งสองฝั่ง

ทดสอบเส้นทาง ไม่ใช่ ping

trace ที่แยกทันเนลที่ใช้งานได้ออกจากเส้นทางที่ใช้งานได้มีลักษณะเช่นนี้ ฮอปแรกคือเกตเวย์ภายในองค์กร จากนั้นมีฮอปที่ไม่ตอบบ้าง แล้วโฮสต์ปลายทางจึงตอบ หาก trace ไม่ถึงโฮสต์เลย ให้ทดสอบพอร์ต TCP ที่แอปพลิเคชันใช้จริง เพราะ ICMP ถูกกรองบ่อยพอที่ ping ที่ล้มเหลวจะพิสูจน์ได้น้อยมาก รัน trace เดียวกันจากโฮสต์ปลายทางไปยังเครื่องเสมือนใน Azure ความไม่สมมาตรระหว่างผลสองอย่างคือวิธีที่เร็วที่สุดในการหาเส้นทางขากลับที่หายไปหรือกฎที่อนุญาตเพียงทิศเดียว

เขียนข้อเสนอของ peer พื้นที่แอดเดรสทั้งสอง และเวลาที่สร้างการเชื่อมต่อลงในตั๋ว เพื่อให้วิศวกรคนถัดไปรู้ว่าค่าใดถูกสร้างใหม่และค่าใดไม่เคยถูกแตะ

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