ตำแหน่งที่ควรใช้ NSG กับทราฟฟิก VPN แบบไซต์ทูไซต์ของ Azure

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

วาง NSG ในตำแหน่งที่ Azure ประเมิน

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

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

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

az network vnet subnet show -g rg-net -n snet-app --vnet-name vnet-prod --query networkSecurityGroup.id
az network vnet subnet show -g rg-net -n GatewaySubnet --vnet-name vnet-prod --query networkSecurityGroup.id

ค้นหาที่อยู่ซอร์สหลังการถอดรหัส

ซอร์สภายในคือที่อยู่ส่วนตัวของไคลเอนต์ภายในองค์กร หรือที่อยู่ที่อุปกรณ์หรือ NAT ของ VPN นำเสนอหลังการแปลที่อยู่ ไม่ใช่ที่อยู่สาธารณะของเกตเวย์ VPN ภายในองค์กรซึ่งเป็นของการแลกเปลี่ยนภายนอก

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

az network nsg rule create -g rg-net --nsg-name nsg-app -n allow-onprem-https --priority 200 --direction Inbound --access Allow --protocol Tcp --source-address-prefixes 192.168.10.0/24 --destination-address-prefixes 10.1.2.0/24 --destination-port-ranges 443

ใช้หนึ่งกฎต่อหนึ่งบริการที่ต้องการเปิดเผย และทำให้รายการพอร์ตสั้น กฎที่อนุญาตทุกพอร์ตจากช่วงภายในองค์กรทำให้ NSG เป็นเพียงพิธีการ

ตรวจสอบขอบเขตเริ่มต้นของ VirtualNetwork

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

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

เอกสารแท็กบริการของ Microsoft ระบุว่าแท็ก VirtualNetwork ครอบคลุมอะไร และเป็นแหล่งอ้างอิงที่ควรอ้างเมื่อมีคนโต้แย้งว่าแท็กหมายถึงเฉพาะช่วง VNet

อ่านกฎที่มีผลที่ขอบเขตทั้งสอง

เมื่อมีทั้ง NSG ของซับเน็ตและ NSG ของ NIC โฟลว์ต้องผ่านทั้งสอง การอนุญาตในตัวหนึ่งไม่ลบล้างการปฏิเสธในอีกตัว และแพ็กเก็ตพบกับมุมมองรวมจริง

az network nic show-effective-nsg -g rg-net -n vm-app-nic -o table

หากมีกฎผู้ดูแลความปลอดภัยของ Azure Virtual Network Manager เกี่ยวข้อง ตรวจทานชั้นนั้นด้วย กฎ Always allow ของผู้ดูแลสามารถส่งทราฟฟิกโดยไม่ประเมิน NSG ขณะที่ Deny ของผู้ดูแลหยุดก่อนที่ NSG จะเห็น การตรวจทานเฉพาะ NSG ไม่ครบถ้วนสำหรับการจัดวางเช่นนั้น

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

ตรวจสอบด้วยการเชื่อมต่อใหม่

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

az network watcher test-ip-flow -g rg-net --vm vm-app --direction Inbound --protocol Tcp --local 10.1.2.4:443 --remote 192.168.10.50:51515

การอนุญาตของ NSG เป็นการตัดสินสิทธิ์ครั้งเดียว ไม่ใช่เส้นทางและไม่ใช่ตัวรับฟัง หากกฎอนุญาตโฟลว์แต่การเชื่อมต่อยังล้มเหลว ให้ตรวจสอบ เส้นทางของไคลเอนต์เข้า VPN เส้นทางกลับของ Azure และไฟร์วอลล์ของโฮสต์ก่อนแก้ไขกลุ่มอีกครั้ง บันทึกที่อยู่ซอร์สจริง ความเชื่อมโยงของ NSG และกฎที่ตรงกันพร้อมบริการที่ได้รับอนุมัติ เพราะการเปลี่ยนแปลง peering หรือเส้นทางครั้งต่อไปอาจเปลี่ยนสิ่งที่แท็ก VirtualNetwork ครอบคลุม