Azure VM เครื่องเดียวต้องใช้ทันเนล: ไคลเอนต์ในเกสต์หรือเกตเวย์ VPN?

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

สองงานที่ดูคล้ายกัน

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

คำขอส่วนใหญ่สำหรับ VM เครื่องเดียวคืองานแรกที่สวมภาษาของงานที่สอง มีคนพูดว่า “VM คือ VPN ของเรา” แต่หมายความว่าแอปพลิเคชันหนึ่งบนนั้นต้องเข้าถึงฐานข้อมูลอีกฝั่ง

เงื่อนไขข้อหนึ่ง: มีอย่างอื่นต้องใช้ฝั่งไกลหรือไม่?

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

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

เงื่อนไขข้อสอง: คุณรักษาเส้นทางบริหารจัดการไว้ได้หรือไม่?

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

ตรวจสอบก่อนและหลัง บน Linux ip route get <management-ip> แสดงว่าอินเทอร์เฟซและแหล่งต้นทางใดที่เคอร์เนลจะใช้ตอนนี้ เปรียบเทียบกับคำตอบขณะที่ทันเนลเปิดอยู่ ทันเนลแบบแยกที่มีรายการปลายทางชัดเจนปกป้องได้ง่ายกว่าเส้นทางเริ่มต้น และมักเป็นสิ่งที่เวิร์กโหลดต้องการจริง ๆ

เงื่อนไขข้อสาม: ใครแพตช์ตอนเที่ยงคืน?

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

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

สิ่งที่เกตเวย์แบบจัดการไม่ได้ทำ

Azure VPN Gateway เป็นบริการเชื่อมต่อ VNet ที่มีรูปแบบไซต์ถึงไซต์และพอยต์ถึงพอยต์ของตัวเอง ไม่ใช่กฎที่ห้ามซอฟต์แวร์ VPN ในเกสต์ และไม่ใช่ตัวแทนโดยตรงของไคลเอนต์ที่แอปพลิเคชันหนึ่งต้องการ

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

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

วางแผนเส้นทางการเติบโตก่อนจะต้องใช้

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

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

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