IP ثابت در Azure P2S VPN: چرا نشانی کلاینت تغییر می‌کند
Azure point-to-site در هر اتصال نشانی آزاد بعدی را از استخر می‌دهد، بنابراین IP ثابت کلاینت وجود ندارد. دسترسی را بر اساس محدوده یا هویت تعریف کنید.
هر کلاینت Azure point-to-site هنگام احراز هویت نشانی‌ای از استخر می‌گیرد و آن را فقط تا پایان همان اتصال نگه می‌دارد. نه جدول رزروی وجود دارد، نه نگاشت به‌ازای هر کاربر، و نه تنظیمی در دروازه که معنایش «همیشه به این شخص 172.16.0.10 بده» باشد. همین یک سازوکار هر دو نشانه‌ای را توضیح می‌دهد که مردم بعداً به آن برمی‌خورند: قاعده NSG که دیگر با کاربری که قبلاً با او منطبق بود منطبق نیست، و فهرست مجاز که بی‌سروصدا ماشینی را می‌پذیرد که کسی عمداً اضافه نکرده است. جایگزین‌کردن قاعده با قاعده‌ای هوشمندتر در IP هیچ‌کدام را درست نمی‌کند، چون چیزی که قاعده نام می‌برد بر اساس زمانی که شما کنترلش نمی‌کنید دوباره اختصاص می‌یابد.
استخر ظرفیت است، نه هویت. وجود دارد تا تونل‌های همزمان نشانی‌های یکتا بگیرند، و به‌محض پایان اجاره آن‌ها را بازیافت می‌کند. وقتی این روشن شد، پرسش سودمند دیگر «چطور این کلاینت را ثابت کنم» نیست و می‌شود «در برابر چه چیزی می‌توانم قاعده‌ای بنویسم که دروازه بازیافتش نکند».
دروازه واقعاً هنگام اتصال کلاینت چه می‌کند
دروازه استخر نشانی‌های کلاینت پیکربندی‌شده را نگه می‌دارد و آن را جدول اجاره می‌بیند. هنگام اتصال نشانی آزاد بعدی را برمی‌دارد، در عمل پایین‌ترین نشانی موجود، و آن را تا زمانی که کلاینت قطع کند یا اجاره پایان یابد به آداپتور تونل اختصاص می‌دهد. ترتیب تصمیم می‌گیرد، نه هویت: هرکس پس از دوره‌ای آرام اول دوباره وصل شود، پایین‌ترین نشانی‌ای را می‌گیرد که در آن لحظه تصادفاً آزاد است.
اندازه استخر رفتار را پنهان می‌کند. استخر آزمایشگاهی که یکی دو نشانی بیشتر از تعداد آزمونگرها دارد قطعی به نظر می‌رسد، چون همان لپ‌تاپ معمولاً هر صبح با همان ترتیب دوباره وصل می‌شود. ماشین سومی اضافه کنید، اندازه استخر را تغییر دهید یا جلسه‌ای را در وقت ناهار متصل بگذارید، و الگو می‌شکند. نشانی هرگز پایدار نبود؛ صف پایدار بود.
هر تغییری در پیکربندی point-to-site فضای اجاره را هم بازنشانی می‌کند. نوع احراز هویت متفاوت، استخری با اندازه دیگر، محدوده استخر جدید، یا دروازه‌ای که تخریب و از نو ساخته می‌شود، همه کلاینت‌ها را به استخری برمی‌گردانند که دیگر با نشانی‌های قدیمی‌شان منطبق نیست. هیچ بخشی از آن تغییر به NSG شما دست نمی‌زند، به همین دلیل خرابی خودبه‌خودی به نظر می‌رسد.
می‌توانید این را در حدود یک دقیقه ببینید. وصل شوید، نشانی تونل را در جزئیات اتصال کلاینت یادداشت کنید، قطع شوید، ماشین دومی را وصل کنید و سپس اولی را دوباره وصل کنید. نشانی‌ای که برمی‌گردد به آنچه ماشین دوم نگه داشته بستگی دارد و هیچ تنظیمی در پرتال آن نشانی قبلی را به‌درخواست بازنمی‌گرداند.
NSG بر پایه IP کلاینت در واقع قاعده‌ای درباره ترتیب اتصال است
قاعده‌ای که مردم اول می‌نویسند همان واضح است: قاعده‌ای ورودی روی NIC ماشین مدیریت یا روی زیرشبکه آن، با نشانی داخلی کلاینت VPN به‌عنوان مبدأ. کوتاه است، روزی که نوشته می‌شود آزمون را می‌گذراند و به‌محض اینکه استخر بیش از یک نشانی آزاد داشته باشد شکست می‌خورد.
دو حالت شکست از این ناشی می‌شود و تنها یکی از آن‌ها مثل باگ به نظر می‌رسد. کاربر مجاز رد می‌شود چون کس دیگری در آن لحظه نشانی‌ای را دارد که قاعده نام می‌برد، و این به‌صورت تیکت پشتیبانی آزاردهنده می‌رسد. یا کاربر ناخواسته پذیرفته می‌شود چون نشانی‌ای را به ارث برده که قاعده هنوز به آن اعتماد دارد، و این هیچ‌گونه به نظر نمی‌رسد تا وقتی کسی دسترسی را حسابرسی کند.
چون قاعده از اجاره پیروی می‌کند، سیاست مؤثر می‌گوید «اولین کسی که وصل شود دسترسی مدیریت می‌گیرد». این توصیف ترتیب اتصال است که لباس نیت پوشیده، و هیچ بهداشتی در قواعد آن را بیانگر نیت نمی‌کند.
اجاره کلاینت و نشانی دروازه دو شیء متفاوت‌اند
بیشتر سردرگمی از یک واژه می‌آید. دروازه IP عمومی نسبتاً پایداری دارد؛ کلاینت‌ها نشانی‌های خصوصی از استخر دارند که پایدار نیستند. برای دروازه VPN غیرمنطقه‌ای، IP عمومی به‌صورت پویا تخصیص می‌یابد، اما از تغییر اندازه، بازنشانی و نگهداری معمول جان سالم به در می‌برد — زمانی تغییر می‌کند که خود دروازه حذف و از نو ساخته شود. SKUهای دروازه منطقه‌ای و دارای افزونگی منطقه از IP عمومی Standard SKU استفاده می‌کنند و آن تخصیص باید ثابت باشد.
همین پایداری چیزی است که همتای محلی در پیکربندی‌اش لازم دارد و هیچ چیزی درباره شناسایی یک کلاینت خاص نمی‌گوید. وقتی شریکی می‌پرسد چه نشانی‌ای خواهد دید، پاسخ IP عمومی دروازه در site-to-site است یا یک محدوده NAT مشترک — هرگز اجاره تونل یک لپ‌تاپ.
استخرهای گروهی محدوده‌ای به شما می‌دهند که نوشتن قاعده در برابرش می‌ارزد
Virtual WAN point-to-site از گروه‌های کاربری پشتیبانی می‌کند و به هر گروه می‌توان استخر نشانی کلاینت خودش را داد. عضویت با هویت تعیین می‌شود، پس محدوده‌ای که کلاینت در آن قرار می‌گیرد قابل پیش‌بینی می‌شود: عملیات در یک محدوده، پیمانکاران در محدوده‌ای دیگر، و محدوده چیزی است که قاعده فایروال یا NSG می‌تواند بدون حدس‌زدن نام ببرد.
مجموعه قواعد حاصل شکلی دارد که می‌توانید بازبینی کنید:
- یک استخر برای هر مخاطب، به اندازه اوج جلسات همزمان و نه تعداد افراد؛
- عضویت گروهی از راه هویت اداره می‌شود، نه با ویرایش قواعد هر بار که کسی می‌پیوندد؛
- قواعد NSG یا Azure Firewall بر اساس محدوده‌های استخر نوشته می‌شوند، هرگز بر اساس اجاره‌های فردی؛
- یک هاب یا دروازه جداگانه برای مخاطبانی که هرگز نباید محدوده‌ای را شریک شوند.
| Rule target | Survives a reconnect | What it still cannot express |
|---|---|---|
| Client tunnel address | No | Follows connection order and admits whoever holds the address next |
| Whole client pool | Yes | Grants every connected client identical access |
| Virtual WAN group pool | Yes | Only as reliable as group membership |
| Gateway public IP | Until the gateway is recreated | Identifies the site, not the person |
گذاشتن کل استخر در فهرست مجاز صادقانه اما خشن است: هر کلاینت متصل در آن محدوده دسترسی یکسان می‌گیرد. این تصمیمی سیاستی است که ارزش دارد بلند گفته شود تا اینکه در بازبینی کشف شود. هر چیزی که هنوز پاسخ به‌ازای هر شخص لازم دارد به منبع تعلق دارد، از راه تخصیص نقش‌ها، نه به فیلتر بسته.
وقتی استقرار نمی‌تواند به Virtual WAN برود
بسیاری از دروازه‌ها دروازه VPN ساده می‌مانند و رفتن به Virtual WAN تغییری ساده نیست. پاسخ عملی این است که تصمیم به‌ازای کاربر را از فیلتر بسته به چیزی منتقل کنید که از قبل می‌داند کاربر کیست.
هویت در سطح منبع ارزان‌ترین نسخه است. Storage، SQL و Key Vault همگی احراز هویت Entra ID را با تخصیص نقش به‌ازای کاربر یا گروه پشتیبانی می‌کنند، پس VPN فقط باید دسترسی شبکه‌ای را اثبات کند. یک میزبان پرش با حساب‌های نام‌دار همان کار را برای کارهای مدیریتی می‌کند، چون میزبان انسان را ثبت می‌کند و تونل فقط بسته حمل می‌کند. ثبت کلاینت‌ها در DNS و مجازکردن نام به‌جای شماره قاعده را یک لایه بالاتر می‌برد. هویت در لایه برنامه — موضوع گواهی، ادعای توکن، عضویت گروه — وقتی کار می‌کند که چیزی که از آن خواسته شده تصمیم بگیرد برنامه باشد، نه شبکه.
برای شریکی که بر نشانی مبدأ ثابت پافشاری می‌کند، پاسخ site-to-site یا ExpressRoute با پیشوند همتای مشخص است. آن‌ها پیشوند همتای را مجاز می‌کنند، نشانی‌ای که در سمتشان ظاهر می‌شود متعلق به دروازه است و وقتی کسی لپ‌تاپی را راه‌اندازی مجدد می‌کند تغییر نمی‌کند.
پیش از ویرایش فهرست مجاز بعدی، استخر را بررسی کنید
دو ویژگی استخر بیشتر رفتارهایی را ایجاد می‌کند که مردم گردن کلاینت می‌اندازند. استخر بیش از حد کوچک اجاره‌ها را سریع بازیافت می‌کند، پس نشانی‌ها دائماً در حال جابه‌جایی به نظر می‌رسند و هر قاعده مبتنی بر نشانی از اساس بی‌ثبات دیده می‌شود. استخری که با محدوده‌های محلی یا فضای شبکه مجازی هم‌پوشانی دارد ابهام مسیریابی ایجاد می‌کند که هیچ قاعده فایروالی آن را درست نمی‌کند.
پیش از دست‌زدن به هر قاعده، سه چیز را در یک صفحه بگذارید: استخر point-to-site، فضای نشانی شبکه مجازی و محدوده‌های محلی. نباید هم‌پوشانی داشته باشند و استخر باید برای هر کلاینت همزمان جا داشته باشد به‌علاوه حاشیه‌ای برای اتصال‌های مجدد.
سپس حلقه را به این ترتیب ببندید:
- از دو ماشین در هر دو ترتیب وصل شوید و نشانی‌ها را مقایسه کنید؛ اگر می‌توانند جابه‌جا شوند، هیچ قاعده مبتنی بر نشانی امن نیست.
- بررسی کنید دروازه Virtual WAN است یا نه؛ اگر هست، به‌جای قواعد هر نشانی از استخرهای گروهی استفاده کنید.
- بپرسید وقتی قاعده‌ای شخص اشتباه را هدف می‌گیرد چه می‌شود؛ اگر پاسخ یک رخداد دسترسی است، کنترل را به هویت منتقل کنید.
- یادداشت کنید کدام محدوده به کدام گروه تعلق دارد، در همان مخزنی که تعریف‌های NSG هست.
- پس از هر تغییر استخر، احراز هویت یا دروازه دوباره آزمون کنید، چون آن تغییرها نگاشت را بی‌آنکه اعلام کنند بازنویسی می‌کنند.