Azure แบบจุดไปยังไซต์เชื่อมต่อได้ แต่ไม่มีทรัพยากรส่วนตัวใดตอบสนอง
เชื่อมต่อแล้วหมายถึงเพียงอุโมงค์ขึ้นมาแล้วเท่านั้น ตรวจสอบว่าเกตเวย์พาอะไรได้บ้าง เปรียบเทียบพื้นที่แอดเดรส แล้วจึงแก้ชื่อและทดสอบบริการนั้นเอง
เชื่อมต่อแล้วเป็นสถานะของอุโมงค์ ไม่ใช่ข้อความเกี่ยวกับการเข้าถึงได้ ลูกค้าแบบจุดไปยังไซต์อาจทำ IKE เสร็จ ได้รับแอดเดรส และยังไปไม่ถึงสิ่งใด เพราะเกตเวย์ส่งต่อทราฟฟิกเฉพาะเครือข่ายที่ VNet รู้จักอยู่แล้ว ทำการตรวจห้าข้อนี้ตามลำดับและหยุดที่ความล้มเหลวแรก การกระโดดข้ามขั้นคือวิธีที่ปัญหา DNS ถูกมองเป็นปัญหาผนังไฟเป็นเวลาหนึ่งชั่วโมง
ลำดับสำคัญกว่ารายการ
การตรวจ 1: ตัดสินใจว่าอุโมงค์ควรพาอะไร
Azure VPN Gateway ยุติอุโมงค์และส่งต่อทราฟฟิกที่เป็นของ VNet; มันไม่ใช่ทางออกอินเทอร์เน็ตทั่วไป. หากผู้ใช้คาดหวังว่าการท่องเว็บของตนจะออกผ่าน Azure การออกแบบก็ผิดตั้งแต่ก่อนที่การตั้งค่าลูกค้าใดจะเข้ามาเกี่ยว เปิด split tunneling เพื่อให้อินเทอร์เน็ตในเครื่องยังใช้เส้นทางในเครื่อง และใช้ NAT instance หรืออุโมงค์แบบไซต์ไปยังไซต์เมื่อจำเป็นต้องมีแอดเดรสออกคงที่จริง ๆ
เขียนว่าลูกค้าควรไปถึงอะไรก่อนทดสอบสิ่งใด หากไม่มีรายการนั้น ทุกผลลัพธ์บางส่วนดูเหมือนความคืบหน้า
การตรวจ 2: เปรียบเทียบพื้นที่แอดเดรสก่อนใบรับรอง
การทับซ้อนตัดสินจากช่วงที่กว้างกว่า ดังนั้นสองเครือข่ายที่ดูต่างกันในระดับซับเน็ตยังชนกันหากบล็อกแม่ทับซ้อนกัน ซับเน็ตของเกตเวย์ต้องเป็นเฉพาะและใหญ่พอสำหรับ SKU และพูลแอดเดรสของลูกค้าต้องไม่ชนกับ VNet หรือสิ่งใดที่เข้าถึงได้ผ่าน peering เปลี่ยนแผนและปรับใช้ใหม่ เพราะการเพิ่มเส้นทางเพื่อชดเชยทำให้เกิดอุโมงค์ที่ทำงานกับบางปลายทางและไม่ทำงานกับบางปลายทางอย่างอธิบายไม่ได้ การจัดเตรียมล้มเหลวเสียงดังตรงนี้ ซึ่งเป็นกรณีที่ดี
การพิสูจน์ตัวตนคือประตูถัดไป โปรไฟล์ใบรับรอง RADIUS และ Entra ID ใช้แทนกันไม่ได้ และแพ็กเกจลูกค้าแตกต่างกันในแต่ละแบบ
การตรวจ 3: แก้ชื่อส่วนตัวจากภายใน
ลูกค้าเก็บตัวแก้ชื่อของตนเอง เว้นแต่โปรไฟล์ที่ดาวน์โหลดมามีเซิร์ฟเวอร์ DNS ของ VNet และรายการนั้นถูกฝังในเวลาดาวน์โหลด เพิ่ม forwarder ภายใน VNet ตั้งเป็นเซิร์ฟเวอร์ DNS ของ VNet แล้วดาวน์โหลดและนำเข้าแพ็กเกจลูกค้าอีกครั้ง การใช้แพ็กเกจเก่าซ้ำทดสอบเพียงรายการตัวแก้ชื่อเก่า
ทดสอบแอดเดรสก่อน เพราะแยกเส้นทางออกจากการตั้งชื่อในขั้นตอนเดียว: Test-NetConnection 10.20.1.4 -Port 3389.
หากแอดเดรสตอบและชื่อไม่ตอบ ให้ถามตัวแก้ชื่อโดยตรงด้วย Resolve-DnsName files.corp.example -Server 10.20.0.4 หากทั้งสองล้มเหลว แสดงว่าความผิดพลาดไม่ใช่ DNS และคุณควรหยุดแก้การตั้งค่า DNS DNS ของแพลตฟอร์ม Azure ที่ 168.63.129.16 ตอบเฉพาะจากภายใน VNet ดังนั้นลูกค้าที่อยู่นอกจึงใช้แอดเดรสนั้นเป็นตัวแก้ชื่อไม่ได้
การตรวจ 4: ทดสอบบริการที่อยู่หลังอุโมงค์
อุโมงค์ที่แข็งแรงและพอร์ตที่ปิดดูเหมือนกันจากฝั่งลูกค้า ตรวจสอบไฟร์วอลล์ของเกสต์ จากนั้นกลุ่มความปลอดภัยเครือข่ายบนซับเน็ตหรือ NIC จากนั้นดูว่าบริการฟังอยู่บนแอดเดรสส่วนตัวหรือเพียง loopback อนุญาตพูลลูกค้าเป็นแหล่งที่มาแทนการเปิดกฎสู่อินเทอร์เน็ต และจำไว้ว่า SMB ไปยัง Azure Files ต้องให้เส้นทาง endpoint ส่วนตัววิ่งผ่านอุโมงค์ เมื่อทรัพยากรตอบด้วย IP แต่ไม่ตอบด้วยชื่อ ให้กลับไปที่การตรวจ 3 แทนการแตะเกตเวย์
ตารางเดียวแยกชั้นข้อมูลออกจากกันขณะทำงาน:
| Symptom | Layer to check |
|---|---|
| Name fails, private IP works | Resolver setting or forwarder |
| Private IP also fails | Address plan, NSG, guest firewall |
| Private works, internet fails | Expected; the gateway is not an egress |
| Connects, then drops | Tunnel type or certificate mismatch |
การตรวจ 5: บันทึกโปรไฟล์ก่อนยกระดับ
ใส่ประเภทเกตเวย์ ประเภทอุโมงค์ วิธีการพิสูจน์ตัวตน และระบบปฏิบัติการของลูกค้าลงในตั๋ว โปรไฟล์ IKEv2 แบบใบรับรองและโปรไฟล์ RADIUS ล้มเหลวด้วยเหตุผลต่างกัน และลูกค้าที่สร้างสำหรับอุโมงค์อีกประเภทจะเชื่อมต่อได้เมื่อเกตเวย์เสนอโปรโตคอลที่เข้ากันเท่านั้น
สำหรับทีมเล็ก การออกแบบที่ยั่งยืนคือ VNet หนึ่งตัว forwarder DNS หนึ่งตัว และลูกค้า split-tunnel ที่มีเอกสาร หากข้อกำหนดคือทางออกสาธารณะคงที่ ให้ยุติอุโมงค์แบบไซต์ไปยังไซต์บนไฟร์วอลล์ที่คุณควบคุมและส่งทราฟฟิกอินเทอร์เน็ตไปที่นั่น แทนที่จะขอให้เกตเวย์แบบจุดไปยังไซต์ทำสิ่งที่ไม่เคยถูกสร้างมาเพื่อสิ่งนั้น