Azure P2S: ไคลเอนต์ Windows เครื่องหนึ่งขาดเส้นทางหลังการเปลี่ยน VNet

แล็ปท็อปสองเครื่องตรวจสอบสิทธิ์กับเกตเวย์ Azure point-to-site เดียวกัน และมีเพียงเครื่องเดียวที่ไปถึง VNet ที่เพิ่งเชื่อมต่อ ทั้งสองแสดง Connected การตรวจสอบสิทธิ์จึงไม่ใช่ความแตกต่าง แต่เส้นทางปลายทางที่แต่ละเครื่องถืออยู่คือความแตกต่าง เริ่มจากไคลเอนต์ที่ล้มเหลว เทียบปลายทางเดียว แล้วจึงตัดสินว่าช่องว่างเป็นของแพ็กเกจเกตเวย์หรือตารางเส้นทางภายในเครื่อง

เริ่มจากไคลเอนต์ที่ล้มเหลว ไม่ใช่เกตเวย์

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

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

เทียบปลายทางเดียวด้วย route print

เลือก IP ของทรัพยากรที่ได้รับอนุญาตและเทียบแล็ปท็อปทั้งสองสองครั้ง คือตอนตัดการเชื่อมต่อและตอนเชื่อมต่อ บน Windows route print -4 แสดงเส้นทาง IPv4 พร้อมคำนำหน้าปลายทาง อินเทอร์เฟซ ฮอปถัดไป และเมตริก บันทึกแถวที่จะชนะจริงสำหรับปลายทางนั้นแทนการนับรายการที่มีคำว่า VPN

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

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

TTL expired ไม่ใช่บั๊กของการกระจายเส้นทาง

ping ที่คืนค่า TTL expired in transit บอกว่าแพ็กเก็ตใช้โควตาฮอปหมด ซึ่งมักหมายถึงลูปการส่งต่อ ไม่ใช่ไดรเวอร์ VPN ที่เสีย ping ของ Windows ยอมรับ TTL ได้ถึง 255 และการเพิ่มค่าไม่ได้ซ่อมลูป มีแต่ทำให้ข้อผิดพลาดเดิมช้าลง มองข้อความเป็นอาการของเส้นทาง ไม่ใช่หลักฐานเกี่ยวกับการกระจายเส้นทาง

ใช้ tracert -4 10.24.1.10 เพื่อดูว่าเส้นทางซ้ำที่ใด หากฮอปสองตัวเดิมปรากฏซ้ำแล้วซ้ำอีก ให้หาเส้นทางที่ส่งทราฟฟิกมุ่งสู่อุโมงค์กลับเข้าอุโมงค์หรือไปยังเราเตอร์ภายในเครื่องที่ส่งกลับมา

สร้างแพ็กเกจใหม่บนเกตเวย์ที่เป็นเจ้าของ

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

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

สถานการณ์การกำหนดเส้นทางของ Azure P2S แยก VNet ที่เพียร์โดยตรงออกจากเครือข่ายที่เข้าถึงผ่านอุโมงค์อื่น และแพ็กเกจใหม่ไม่อาจทำให้การเพียร์ส่งผ่านต่อได้ สถานการณ์ Windows site-to-site หรือ BGP บางแบบยังต้องกำหนดเส้นทางระยะไกลด้วยมือ การรีเฟรชแพ็กเกจจึงไม่ใช่กลไกกระจายเส้นทางแบบสากล

เก็บเส้นทางชั่วคราวให้เป็นชั่วคราว

เส้นทางที่ทำด้วยมือสามารถแยกเส้นทางไคลเอนต์ที่ขาดหายได้ แต่จงสร้างจากดีไซน์จริง: route add 10.24.0.0 mask 255.255.0.0 172.16.0.1 if 42 โดยไม่มีแฟล็กถาวร เพื่อให้หายไปเมื่อรีบูต เลือกดัชนีอินเทอร์เฟซและฮอปถัดไปจากอะแดปเตอร์ VPN ที่เชื่อมต่ออยู่ ไม่ใช่จากการเดา

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

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