Azure ตรวจสอบโฟลว์ IP บอกว่าอนุญาต แต่ VPN ก็ยังล้มเหลว

อุโมงค์ไซต์ทูไซต์เชื่อมต่อแล้ว VM ปกติดี แต่ไคลเอนต์ฝั่งองค์กรไม่ได้รับอะไรเลย คุณเปิด Network Watcher รันการตรวจสอบโฟลว์ IP แล้วมันบอกว่า Access allowed ทิกเก็ตจึงถูกปิดว่าเป็นปัญหา VPN ผลลัพธ์นั้นไม่ได้หมายความอย่างที่เห็น เพราะการตรวจสอบโฟลว์ IP ประเมินกฎความปลอดภัยของโฟลว์ที่คุณอธิบาย และไม่เคยทดสอบว่า Azure มีเส้นทางไปยังคำนำหน้าฝั่งองค์กรของคุณหรือไม่

คำถามเรื่องการกรองกับคำถามเรื่องการกำหนดเส้นทางแยกจากกัน และ Network Watcher ตอบด้วยเครื่องมือคนละอย่าง การรู้ว่าคุณถามคำถามไหนคือหัวใจของการวินิจฉัย

การตรวจสอบโฟลว์ IP ตัดสินอะไรจริง ๆ

การตรวจสอบโฟลว์ IP รับ VM อินเทอร์เฟซเครือข่าย ทิศทาง ค่าห้าองค์ประกอบ และโปรโตคอล แล้วรายงานการตัดสินของกฎ NSG และผู้ดูแลความปลอดภัยสำหรับโฟลว์นั้น ทำงานบน TCP และ UDP จึงไม่ใช่เครื่องทดสอบกฎ ICMP และ ping ที่ถูกบล็อกไม่ได้พิสูจน์อะไรเกี่ยวกับบริการของคุณ ให้โฟลว์จริงแทนการเดา การเชื่อมต่อขาเข้าจากฝั่งองค์กรไปยังพอร์ตฐานข้อมูลเป็นคำอธิบายที่ต่างจากการเชื่อมต่อขาออกที่ VM เริ่ม

ถ้าเกตเวย์แปลที่อยู่ ให้ใช้ที่อยู่ต้นทางที่ไปถึงขอบเขตที่คุณกำลังประเมิน ไม่ใช่ที่อยู่ในคอนฟิกไคลเอนต์ อ่านผลลัพธ์ตามที่เป็นด้วย Access allowed หมายความว่าชั้นกรองจะอนุญาตแพ็กเก็ตถ้ามันมาถึง และไม่มากกว่านั้น

สิ่งที่มันบอกคุณไม่ได้คือเส้นทางที่ Azure เลือก ไฟร์วอลล์ของ guest อนุญาตพอร์ตหรือไม่ หรือมีอะไรฟังอยู่หรือไม่ สิ่งเหล่านั้นอยู่ในชั้นอื่น

ฮอปถัดไปและเส้นทางที่มีผลเพิ่มอะไร

ฮอปถัดไปตอบคำถามเรื่องการส่งต่อ: สำหรับปลายทางนี้ Azure เลือกฮอปถัดไปชนิดใด ที่ที่อยู่ใด จากตารางเส้นทางใด เส้นทางที่มีผลแสดงสิ่งที่ NIC มีจริง รันทั้งสองอย่างแล้วคุณจะได้เส้นทางฝั่ง Azure ที่การตรวจสอบโฟลว์ IP สีเขียวทิ้งว่างไว้

ภาพรวมการตรวจสอบโฟลว์ IPของ Microsoft ระบุขอบเขตการกรองโดยตรง ขณะที่หน้าฮอปถัดไปและการวินิจฉัยเส้นทางครอบคลุมฝั่งการส่งต่อ อ้างอิงหน้าที่ถูกต้องเมื่อเขียนข้อค้นพบ

คำสั่งสั้นพอที่จะรันจากเชลล์ az network nic show-effective-route-table แสดงเส้นทางที่ใช้กับอินเทอร์เฟซ az network watcher show-next-hop พร้อมต้นทางและปลายทางจะคืนฮอปที่เลือก เปรียบเทียบคำนำหน้าที่คุณสนใจกับตารางนั้น แล้วยืนยันว่ารายการใดชนะ.

เดินเส้นทางขากลับจาก NIC ของ VM

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

ถ้าเส้นทางที่คาดไว้หายไป ให้ตรวจสอบคำนำหน้าปลายทางไกลที่คอนฟิกเกตเวย์ให้ การออกแบบการเชื่อมต่อ VNet และการตั้งค่าการกระจายเส้นทางใด ๆ การมีอยู่ของออบเจ็กต์เกตเวย์เครือข่ายภายในไม่ได้พิสูจน์ว่าคำนำหน้าที่จำเป็นทุกตัวมีอยู่และถูกเลือกบน NIC สิ่งเหล่านี้เป็นข้อเท็จจริงคนละอย่าง และมีเพียงอย่างเดียวที่ปรากฏในสรุปของพอร์ทัล

อ่านชนิดฮอปถัดไปแทนการคัดลอกตัวอย่าง

เส้นทางผ่านเกตเวย์ VPN ที่จัดการมักแสดง VirtualNetworkGateway เป็นชนิดฮอปถัดไป VirtualAppliance อธิบายการออกแบบการส่งต่อที่ต่างออกไป โดยปกติคือไฟร์วอลล์หรืออุปกรณ์เครือข่ายเสมือน

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

ย้ายไปที่ขอบเขตที่ยังล้มเหลว

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

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