ทำไม point-to-site ต้องใช้เกตเวย์ Azure VPN แบบอิงเส้นทาง

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

ลำดับสำคัญกว่าขั้นตอนแต่ละขั้น หากลำดับผิด การหยุดชะงักระหว่างไซต์จะลากยาวเกินหน้าต่างบำรุงรักษา

เกตเวย์แบบอิงนโยบายทำอะไรจริง ๆ

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

เกตเวย์แบบอิงเส้นทางทำงานตรงกันข้าม มันนำเสนออินเทอร์เฟซทันเนล และเส้นทางเป็นตัวตัดสินว่าอะไรเข้าสู่ทันเนล การเชื่อมต่อ point-to-site และการออกแบบใดที่ชุดคู่ค้าเปลี่ยนแปลง ขึ้นอยู่กับการมีอยู่ของอินเทอร์เฟซนั้น

ทำไมพูลไคลเอนต์จึงต้องมีอินเทอร์เฟซนั้น

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

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

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

ชนิดถูกกำหนดตอนสร้าง

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

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

เกตเวย์เดียว GatewaySubnet เดียว

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

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

สิ่งที่การแทนที่ไม่แก้ไข

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

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

ลำดับการดำเนินการและการตรวจสอบ

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

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