Áp dụng NSG ở đâu cho lưu lượng VPN site-to-site của Azure

Đường hầm site-to-site đang hoạt động, máy khách tại chỗ đến được một số máy chủ Azure và không đến được số khác, và ai đó đã gắn một nhóm bảo mật mạng vào GatewaySubnet để khắc phục. Dừng lại ở đó. Azure không hỗ trợ NSG trên GatewaySubnet, và nhóm không thấy gói bên trong như một quy tắc khối lượng công việc. Đặt chính sách trên subnet hoặc NIC đích, khớp địa chỉ nguồn tồn tại sau khi giải mã, rồi kiểm chứng bằng kết nối mới chứ không phải kết nối cũ.

Đặt NSG ở nơi Azure đánh giá nó

Ranh giới được hỗ trợ cho việc lọc khối lượng công việc là subnet hoặc giao diện mạng đích. Subnet cổng là hạ tầng, và Azure ghi nhận rằng NSG không được hỗ trợ ở đó và có thể làm hỏng hoạt động của cổng.

Cũng có vấn đề logic về vị trí. NSG trên GatewaySubnet sẽ đánh giá trao đổi IPsec bên ngoài, mà địa chỉ thuộc về hai cổng. Quy tắc ứng dụng của bạn cần nguồn riêng bên trong đường hầm, và gói đó chỉ tồn tại sau khi cổng giải mã nó. Gắn nhóm vào subnet khối lượng công việc và quy tắc sẽ thấy địa chỉ mà nó được viết cho.

Kiểm tra các liên kết hiện tại trước khi thay đổi bất cứ điều gì, để biết bạn đang di chuyển cái gì:

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

Tìm địa chỉ nguồn sau khi giải mã

Nguồn bên trong là địa chỉ riêng của máy khách tại chỗ, hoặc địa chỉ mà một thiết bị hay NAT của VPN trình bày sau khi dịch. Đó không phải địa chỉ công khai của cổng VPN tại chỗ, vốn thuộc trao đổi bên ngoài.

Khi NAT là một phần của thiết kế, hãy xác nhận nguồn được trình bày thay vì giả định. Việc bắt gói trên VM Azure, hoặc trường nguồn trong nhật ký kết nối của dịch vụ, giải quyết câu hỏi nhanh hơn đọc cấu hình tại chỗ. Sau đó viết quy tắc cho địa chỉ đó và cổng đích thực.

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

Dùng một quy tắc cho mỗi dịch vụ bạn muốn mở, và giữ danh sách cổng ngắn. Một quy tắc cho phép mọi cổng từ dải tại chỗ biến NSG thành thủ tục hình thức.

Kiểm tra phạm vi mặc định của VirtualNetwork

Thẻ dịch vụ VirtualNetwork rộng hơn mạng ảo cục bộ. Định nghĩa của nó bao gồm không gian địa chỉ tại chỗ được kết nối, mạng ngang hàng và các tiền tố khác kết nối qua cổng. Vì vậy một quy tắc cho phép mặc định giới hạn ở VirtualNetwork có thể đã cho phép lưu lượng đường hầm mà người vận hành cho là bên ngoài.

Đọc các quy tắc mặc định trước khi thêm quy tắc hẹp, và đọc mọi quy tắc có ưu tiên cao hơn có thể khớp trước. Thêm một cho phép rõ ràng không loại bỏ quy tắc rộng hơn vốn đã cho phép luồng. Nơi chính sách yêu cầu từ chối, hãy đặt nó ở mức ưu tiên thực sự được đánh giá trước cho phép.

Tài liệu về thẻ dịch vụ của Microsoft liệt kê những gì thẻ VirtualNetwork bao gồm, và đó là tài liệu tham chiếu cần trích dẫn khi ai đó lập luận rằng thẻ chỉ có nghĩa là dải VNet.

Đọc các quy tắc hiệu lực ở cả hai ranh giới

Khi cả NSG subnet và NSG NIC cùng áp dụng, luồng phải thỏa mãn cả hai. Cho phép ở một cái không vô hiệu hóa từ chối ở cái kia, và gói thực sự gặp chế độ xem tổng hợp.

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

Nếu có các quy tắc quản trị bảo mật của Azure Virtual Network Manager, hãy xem lại lớp đó nữa. Quy tắc quản trị Always allow có thể chuyển lưu lượng mà không cần đánh giá NSG, trong khi Deny quản trị chặn trước khi NSG thấy. Việc chỉ xem xét NSG là chưa đầy đủ cho cách bố trí đó.

Hãy nhớ NSG có trạng thái. Chỉnh sửa quy tắc không nhất thiết kết thúc một kết nối đã được cho phép, nên bài kiểm tra chấp nhận cần luồng mới. Thuộc tính đó hữu ích trong sản xuất và gây nhầm lẫn trong cửa sổ thay đổi.

Kiểm chứng bằng kết nối mới

Mở phiên mới từ máy khách tại chỗ đến cổng dịch vụ, rồi lặp lại từ một máy chủ đáng lẽ bị từ chối. Chạy thử luồng từ phía VM nữa, để biết đường về còn nguyên vẹn.

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

Cho phép của NSG là một quyết định truy cập, không phải tuyến đường và không phải trình lắng nghe. Nếu quy tắc cho phép luồng mà kết nối vẫn thất bại, hãy kiểm tra tuyến của máy khách vào VPN, tuyến về của Azure và tường lửa của máy chủ trước khi sửa nhóm lần nữa. Ghi lại địa chỉ nguồn thực, các liên kết NSG và quy tắc khớp cùng với dịch vụ đã được phê duyệt, vì thay đổi peering hoặc tuyến tiếp theo có thể làm thay đổi những gì thẻ VirtualNetwork bao gồm.