NAT ของ Azure VPN ไม่ได้แก้ปัญหา VNet ที่มีที่อยู่ทับซ้อนกัน
VNet สองเครือข่ายที่มีช่วงไพรเวตเดียวกันจะไม่เชื่อมต่อกันเพียงเพราะมี NAT ตรวจสอบประเภทการเชื่อมต่อก่อน จากนั้นจึงกำหนดเลขหมายใหม่หรือเป็นเจ้าของนามแฝงการแปล
VNet ทั้งสองใช้ 10.40.1.0/24 อุโมงค์ขึ้นมาแต่ไม่มีอะไรทำงาน การเพิ่ม VPN เกตเวย์ตัวที่สองไม่เปลี่ยนสิ่งนั้น และเมตริกเส้นทางที่ต่ำลงก็ไม่เปลี่ยนเช่นกัน เพราะปัญหาไม่ใช่การเลือกเส้นทาง งานสองชิ้นที่ตอบสนองต่อที่อยู่ไพรเวตเดียวกันทำให้ทุกแพ็กเก็ตมีปลายทางที่กำกวมและเส้นทางตอบกลับที่ตรวจสอบไม่ได้ ก่อนจะวางแผนการแปลใด ๆ จงค้นหาว่าคุณสร้างการเชื่อมต่อประเภทใดจริง เพราะตัวเลือกเดียวนั้นเป็นตัวกำหนดว่าฟีเจอร์ NAT ของ Azure มีให้ใช้หรือไม่เลย
อาการนี้กำลังบอกอะไรคุณจริง ๆ
เมื่อโฮสต์ใน VNet A ส่งไปยัง 10.40.1.10 ตารางเส้นทางทำได้เพียงชี้ไปที่ใดที่หนึ่ง หาก VNet B มี 10.40.1.10 ด้วย ที่อยู่นั้นไม่ใช่ปลายทางที่เส้นทางแยกแยะได้ มันคือที่อยู่เดียวที่มีเจ้าของสองราย
เกตเวย์ตัวที่สองที่ผู้คนมักติดตั้งไม่ช่วยอะไร มันให้อุโมงค์อีกเส้น ไม่ใช่ที่อยู่อีกที่อยู่ และช่วงที่ซ้ำกันเดินทางภายในอุโมงค์โดยไม่เปลี่ยนแปลง มันยังเพิ่มการกำหนดค่าเป็นสองเท่าที่คุณต้องรักษาให้สอดคล้อง สิ่งที่มันทำไม่ได้คือทำให้ที่อยู่หนึ่งหมายถึงโฮสต์สองเครื่อง
การเปลี่ยนที่อยู่สาธารณะของเพื่อน VPN ก็ไม่ทำอะไรเช่นกัน ที่อยู่เหล่านั้น ระบุจุดปลายของอุโมงค์ ในขณะที่การชนกันอยู่ในช่วงไพรเวตที่บรรทุกอยู่ภายใน
ประเภทการเชื่อมต่อเป็นตัวกำหนดว่า NAT ใช้ได้หรือไม่
Azure VPN Gateway มีความสามารถ NAT จริง และมีการบันทึกไว้สำหรับการเชื่อมต่อ IPsec ข้ามสถานที่แบบอิงเส้นทางบน SKU เกตเวย์ที่ระบุ การบันทึกเดียวกันนั้นยกเว้นการเชื่อมต่อ VNet-to-VNet และ point-to-site ดังนั้นฟีเจอร์นี้จึงไม่ใช่ช่องทำเครื่องหมายที่ปรากฏในทุกความสัมพันธ์ของเกตเวย์
| Connection type | NAT support | Overlap workaround |
|---|---|---|
| Site-to-Site (route-based IPsec, documented SKUs) | Supported with configured NAT rules | Translate the range in the rules |
VNet-to-VNet (Vnet2Vnet) | Not supported | Renumber, or redesign as a site-to-site connection |
| Point-to-site | Not supported | Choose client address pools that do not collide |
VNet-to-VNet แบบเนทีฟยังกำหนดให้ช่วง VNet และเครือข่ายภายในองค์กรไม่ทับซ้อนกันตั้งแต่แรก ซึ่งสอดคล้องกับการยกเว้น การเพียร์ VNet ก็ไม่ใช่วิธีแก้ปัญหาการทับซ้อนด้วยเหตุผลเดียวกัน
มีทางเลือกที่รองรับซึ่งผู้คนมักสับสนกับประเภทเนทีฟ: จำลอง VNet อีกเครือข่ายเป็นเครือข่ายภายในและเชื่อมเป็นลิงก์ระหว่างสถานที่ นั่นเป็นทรัพยากรอื่นและการออกแบบอื่น ดังนั้นจงถือว่าการเชื่อมต่อที่เปลี่ยนชื่อเป็นการเปลี่ยนแปลงที่ต้องตรวจสอบ ไม่ใช่เพียงการเปลี่ยนชื่อ
กำหนดเลขหมายใหม่ หรือแปลด้วยสิ่งที่ครอบครองนามแฝงนั้น
หาก VNet ทั้งสองเป็นของคุณ จงเปรียบเทียบการกำหนดเลขหมายใหม่ตามแผนกับต้นทุนต่อเนื่องของการแปล การกำหนดเลขหมายใหม่แตะการกำหนดค่าแอปพลิเคชัน บันทึก DNS กฎความปลอดภัย และทุกการเชื่อมต่อที่มีอยู่ แต่ทิ้งเครือข่ายที่อ่านได้ตามปกติในภายหลัง ทำทีละซับเน็ต โดยเปลี่ยน DNS เป็นลำดับสุดท้าย ช่วงที่กำหนดเลขหมายใหม่ครึ่งเดียวนั้นแย่กว่าทั้งสองทางเลือก เพราะจากนั้นคำนำหน้าทั้งสองดูน่าเชื่อถือสำหรับผู้ที่อ่านตารางครั้งถัดไป
ในกรณีที่การกำหนดเลขหมายใหม่ไม่เป็นจริง ให้ใช้การออกแบบที่แปลแล้วซึ่งมีเจ้าของที่แท้จริงสำหรับนามแฝง ผู้เรียกใน VNet A อาจเข้าถึง 10.40.1.10 ของ VNet B ในลักษณะ 10.140.1.10 แต่นามแฝงนั้นต้องมีอุปกรณ์ที่แปล เส้นทางไปยังอุปกรณ์นั้น และพฤติกรรมที่สอดคล้องสำหรับคำตอบ ที่อยู่ที่เพิ่มใน DNS เพียงอย่างเดียวไม่ใช่การแปล
บันทึกทั้งสองช่วงในทั้งสองทิศทาง: ผู้เรียกหมุนหมายเลขอะไร ปลายทางเห็นอะไรเป็นต้นทาง และฝ่ายใดเริ่มได้ กฎ NAT ของ Azure เองรวมการแปลย้อนกลับสำหรับการแมป SNAT ดังนั้นคุณไม่ต้องเขียนกฎ DNAT ที่ตรงกันด้วยมือ แต่ความสะดวกนั้นสิ้นสุดที่ประเภทการเชื่อมต่อที่ฟีเจอร์รองรับ
สิ่งที่จะไม่ทำงาน
เส้นทางที่ผู้ใช้กำหนดหรือเมตริกเส้นทางไม่สามารถสร้างความแตกต่างของที่อยู่ที่ขาดหายได้ ทั้งสองทำงานบนปลายทางที่ยังกำกวม และแพ็กเก็ตไปถึงฮอปถัดไปที่ตารางให้ความสำคัญ
การเพิ่มช่วงที่ซ้ำลงในตารางเส้นทางเป็นคำนำหน้าที่เฉพาะเจาะจงกว่าย้ายความกำกวมเพียงก้าวเดียว นอกจากนี้ยังมักทำให้ทิศทางตรงข้ามเสียหาย ซึ่งคำตอบมีต้นทางที่เป็นไปได้สองแห่ง
ยอมรับการออกแบบด้วยทราฟฟิกทั้งสองทิศทาง
พิสูจน์การออกแบบด้วยการดำเนินการที่ได้รับอนุญาตใหม่จากแต่ละฝ่าย ไม่ใช่ด้วยสถานะอุโมงค์ อุโมงค์ IPsec ที่เชื่อมต่อแล้วบอกว่าคู่สัญญาเห็นพ้องเรื่องการเข้ารหัส ไม่ได้บอกอะไรว่าปลายทางแยกแยะได้หรือไม่
จากนั้นรันเส้นทางที่ถูกปฏิเสธ: ที่อยู่ที่ควรเข้าถึงไม่ได้ และบริการที่แนวนโยบายควรบล็อก หากทั้งสองยังสำเร็จ การแปลก็กว้างกว่าที่การออกแบบตั้งใจ
ปิดท้ายด้วยข้อเท็จจริงที่อธิบายการตั้งค่านี้ในภายหลัง: ช่วงเดิม ช่วงที่นำเสนอ อุปกรณ์ที่แปล และทิศทางที่แต่ละฝ่ายเริ่มได้ หากขาดอย่างใดอย่างหนึ่ง วิศวกรคนถัดไปจะได้รับเครือข่ายที่โฮสต์สองเครื่องใช้ชื่อร่วมกันและไม่มีใครจำได้ว่าทำไมเครื่องหนึ่งจึงตอบสนอง