RRAS บน Azure VM ไม่ได้รับการสนับสนุน: ตรวจสอบก่อนออกแบบ

คุณเปิดพอร์ทัล ปรับใช้ Windows Server 2022 ลงในซับเน็ต และบทบาท Remote Access ติดตั้งได้อย่างราบรื่น ลำดับนั้นพิสูจน์ว่าตัวติดตั้งทำงาน ไม่ได้พิสูจน์ว่า Microsoft สนับสนุนการกำหนดค่านี้ แนวทางสนับสนุนซอฟต์แวร์เซิร์ฟเวอร์ที่เผยแพร่สำหรับเครื่องเสมือน Azure ระบุ RRAS ไว้ในกลุ่มคุณลักษณะ Windows Server ที่ไม่ได้รับการสนับสนุนบน Azure VM และนั่นเป็นการตัดสินใจเชิงสถาปัตยกรรม ไม่ใช่รายละเอียดการแก้ปัญหา อุโมงค์ที่ขึ้นมาไม่ได้ย้ายการปรับใช้เข้าไปในขอบเขตการสนับสนุน

คำแนะนำด้านล่างเริ่มที่หน้าสนับสนุน แล้วขยายออกไปยังข้อกำหนดและตัวเลือกการแทนที่

เริ่มที่หน้าสนับสนุน ไม่ใช่ในแล็บ

อ่าน แนวทางสนับสนุน Azure VM ก่อนกำหนดขนาดใดๆ แนวทางแยกผลิตภัณฑ์ บทบาท และคุณลักษณะที่สนับสนุน แทนที่จะถือว่า Windows Server เป็นบล็อกเดียวที่ไม่แตกต่างกัน สังเกตว่าภาระงานที่ตั้งใจไว้อยู่ภายใต้แถวใดจริงๆ เพราะองค์ประกอบสองอย่างที่ดูเกี่ยวข้องกันในคอนโซลอาจอยู่คนละแถว

เขียนการอ้างอิงลงในเอกสารออกแบบขณะที่หน้ายังเปิดอยู่ สถานะการสนับสนุนเป็นข้อเท็จจริงที่มีแหล่งที่มา และการทบทวนการออกแบบที่ไม่สามารถอ้างอิงได้จะถูกโต้แย้งโดยคนที่มีเดโม

แยกการสนับสนุนระบบปฏิบัติการออกจากการสนับสนุนบทบาทและคุณลักษณะ

แนวทางเดียวกันระบุ Network Policy and Access Services ไว้ในบทบาทที่สนับสนุน ขณะที่ระบุ RRAS แยกต่างหากว่าไม่สนับสนุน สองรายการนั้นอธิบายสิ่งที่แตกต่างกัน และการหลอมรวมเป็น “การเข้าถึงระยะไกลได้รับการสนับสนุน” คือวิธีที่โครงการได้รับการอนุมัติจากการอ่านผิด ระบบปฏิบัติการที่ได้รับการสนับสนุนไม่ได้บอกอะไรเกี่ยวกับคุณลักษณะที่มีแถวของตัวเอง

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

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

เขียนว่าการออกแบบต้องทำอะไรจริงๆ

ก่อนเลือกสิ่งทดแทน ให้เปลี่ยนรายการไซต์เป็นข้อกำหนดที่วัดผลิตภัณฑ์ได้:

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

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

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

ประเมินสิ่งทดแทนเทียบกับข้อกำหนดเหล่านั้น

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

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

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

หาก RRAS VM ทำงานอยู่แล้ว

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

รักษาความสามารถในการสนับสนุนและการวินิจฉัยทางเทคนิคเป็นข้อค้นพบแยกกันตลอดเวลา การจัดวางที่ไม่ได้รับการสนับสนุนอาจมีข้อผิดพลาดในการกำหนดเส้นทางธรรมดาได้ด้วย และการแก้ไขข้อผิดพลาดนั้นไม่เปลี่ยนสถานะการสนับสนุน ทั้งสองข้อความอยู่ในรายงาน และไม่มีข้อใดหักล้างอีกข้อ

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