کجا 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 از شبکه مجازی محلی گسترده‌تر است. تعریف آن فضاهای نشانی محلی متصل، شبکه‌های همتا و پیشوندهای دیگر متصل به دروازه را در بر می‌گیرد. یعنی یک قاعده مجاز پیش‌فرض محدود به VirtualNetwork می‌تواند از پیش ترافیک تونلی را مجاز کند که بهره‌بردار آن را بیرونی می‌پنداشت.

پیش از افزودن قاعده‌های باریک، قاعده‌های پیش‌فرض را بخوانید و هر قاعده با اولویت بالاتر را که ممکن است نخست تطبیق یابد بخوانید. افزودن یک مجوز صریح، قاعده گسترده‌تری را که جریان را از پیش مجاز می‌کند حذف نمی‌کند. جایی که خط‌مشی منع می‌خواهد، آن را در اولویتی بگذارید که واقعاً پیش از مجوز ارزیابی شود.

مستندات برچسب‌های سرویس مایکروسافت فهرست می‌کند که برچسب VirtualNetwork چه چیزی را پوشش می‌دهد و همان مرجعی است که وقتی کسی استدلال می‌کند برچسب فقط محدوده VNet را می‌گوید به آن استناد می‌کنید.

قاعده‌های مؤثر را در هر دو مرز بخوانید

وقتی هم NSG زیرشبکه و هم NSG کارت شبکه اعمال می‌شوند، جریان باید هر دو را برآورده کند. مجوز در یکی، منع در دیگری را باطل نمی‌کند و نمای تجمیعی همان چیزی است که بسته واقعاً با آن روبه‌رو می‌شود.

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 و قاعده منطبق را همراه با سرویس تأییدشده ثبت کنید، چون تغییر بعدی همتا یا مسیر می‌تواند پوشش برچسب VirtualNetwork را دگرگون کند.