چرا افزودن یک پیشوند Azure VPN اتصال را قطع میکند
پیشوند دور در دروازه شبکه محلی قرار دارد، نه در VNet. تغییر آن اتصال را حذف میکند؛ خود دروازه دستنخورده میماند.
پیشوندی که به شیء اشتباه Azure اضافه میشود اتصالی میسازد که Connected گزارش میکند و هیچ چیزی را هدایت نمیکند، و این گرانترین نوع خطا در این پشته است. سه منبع درگیرند و تنها یکی از آنها مالک فضای نشانی دور است: دروازه شبکه مجازی، دروازه شبکه محلی که سمت دور را توصیف میکند، و اتصالی که آنها را به هم میپیوندد. پیشوند به دروازه شبکه محلی تعلق دارد، اتصال باید برای اعمال تغییر دوباره ساخته شود، و خود دروازه معمولاً دستنخورده میماند. ترتیب قابل مذاکره نیست، و پرتال تنها بخشی از آن را نشان میدهد.
سه شیء که یکی از آنها پیشوند را نگه میدارد
فضای نشانی شبکه مجازی به پرسش دیگری پاسخ میدهد: چه چیزی درون Azure زندگی میکند. افزودن پیشوند دور در آنجا ترافیک را به آن مسیر نمیدهد، فقط فضایی را گسترش میدهد که پلتفرم تصور میکند مالک آن است، و این میتواند با محدوده واقعی دور تلاقی کند. دروازه شبکه محلی همان شیئی است که پیشوندهای دور را نگه میدارد، و اتصال به هر دو دروازه بهعلاوه یک کلید از پیش مشترک ارجاع میدهد.
یک رزرو سوم هم هست که باید در نظر داشت. GatewaySubnet نمونههای مدیریتشده دروازه را میزبانی میکند، باید دقیقاً همان نام را داشته باشد، و برای SKUهای غیر Basic انتظار میرود دستکم /27 باشد.
هیچ چیز دیگری به آن زیرشبکه تعلق ندارد، و تغییر پیشوند دلیلی برای دست زدن به آن ندارد. پیشوندی که در دروازه شبکه محلی غایب باشد، هر چه وضعیت اتصال بگوید دستنیافتنی است، زیرا دروازه هنگام مذاکره تونل تنها پیشوندهایی را پیشنهاد میدهد که به آن اطلاع داده شده است. به همین دلیل نشانه نامتقارن است: تونل بالاست، انجمن امنیتی درست است، و یک زیرشبکه هرگز در انتخابگرهای ترافیک ظاهر نمیشود. اگر یک محدوده دور غایب باشد در حالی که همسایههایش کار میکنند، نگاه به تونل را رها کنید و دروازه شبکه محلی را بخوانید.
چرا همان اتصال حذف میشود
شیء اتصال پیکربندی مذاکرهشده را برای تمام عمر خود تثبیت میکند. به همین دلیل رویه مستند ابتدا اتصال را حذف میکند، دروازه شبکه محلی را بهروزرسانی میکند، و سپس اتصال را با همان کلید مشترک دوباره میسازد. نمونههای دروازه برای تغییری که فقط پیشوند را در بر میگیرد بازسازی نمیشوند، و این قطعی را به برچیدن اتصال محدود میکند نه به استقرار مجدد دروازه.
آن حذف همان قطعی است، پس با آن مانند یک تغییر زمانبندیشده با شروع و پایان مورد انتظار رفتار کنید، نه مانند یک ویرایش سریع. در PowerShell توالی کوتاه است: Remove-AzVirtualNetworkGatewayConnection -Name Conn1 -ResourceGroupName RG1 -Force، سپس Set-AzLocalNetworkGateway با -AddressPrefix آرایه جدید، سپس New-AzVirtualNetworkGatewayConnection با همان -SharedKey و همان دروازهها. استفاده دوباره از کلید اهمیت دارد، زیرا سمت دور بازپیکربندی نمیشود و کلید تازه یعنی هماهنگی با کسی که دستگاه دور را در اختیار دارد. اگر تیم دیگری آن دستگاه را اداره میکند، پیش از حذف هر چیزی پنجره زمانی را با آنها توافق کنید.
چه زمانی خود دروازه باید بازسازی شود
پاسخ دومی که حول این مشکل میچرخد میگوید دروازه باید دوباره ساخته و کلید دوباره مبادله شود. این برای مجموعه دیگری از عملیات درست است: تغییر نوع دروازه یا SKU، جابهجایی میان نقطهبهنقطه و سایتبهسایت، یا تعمیر دروازهای که پیکربندی خودش اشتباه است. آن تغییرها واقعاً منبع دروازه را تغییر میدهند، پس بازسازی واقعاً لازم است.
دروازهای که برای نقطهبهنقطه ساخته شده نمیتواند بهسادگی اتصال سایتبهسایت بگیرد. پیکربندی نقطهبهنقطه باید حذف و دروازه دوباره ساخته شود، که کلید مشترک تازه و بسته کلاینت تازه هم تولید میکند.
بسته نقطهبهنقطه یادداشت جداگانهای میخواهد زیرا منقضی میشود. پرتال فایلی با عمر کوتاه تولید میکند، پس رویکرد عملی این است که آن را یک بار دانلود کنید و همراه گواهی کلاینت توزیع کنید، نه اینکه پیوند پرتالی برای کاربران بفرستید که تا زمان کلیک آنها مرده باشد. برای پرسش پیشوند هیچیک از اینها صدق نمیکند. جدا نگه داشتن دو رویه تمام انضباط است: پیشوندها تغییری در سطح اتصالاند، و ویژگیهای دروازه تغییری در سطح دروازه.
وضعیت را بخوانید، نه نشان پرتال را
وضعیت را از منبع بخوانید نه از نشان در پرتال. Get-AzVirtualNetworkGatewayConnection -Name Conn1 -ResourceGroupName RG1 برمیگرداند ConnectionStatus را همراه با شمارندههای بایت ورودی و خروجی، و همین شمارندهها تونلی را که متصل است و چیزی حمل نمیکند از تونلی که هرگز برقرار نشد جدا میکنند.
شمارندههایی که در میانه انتقال از افزایش بازمیمانند به مسیر اشاره میکنند نه به احراز هویت. شمارندههایی که اصلاً تکان نمیخورند به مجموعه پیشوندها یا کلید مشترک اشاره میکنند.
زمانسنجها دستهای از قطعها را توضیح میدهند که به اشتباه به VPN نسبت داده میشوند. متعادلکننده بار Azure جریانهای بیکار را پس از مهلت پیکربندیشدهاش میبندد، بهطور پیشفرض چهار دقیقه زمانی که این یادداشتها نوشته شد و قابل افزایش است، بنابراین یک سرور OpenVPN روی ماشین مجازی بدون keepalive میتواند هر چند دقیقه یک بار بیفتد در حالی که همه چیز دیگر سالم به نظر میرسد. دروازهای که پلتفرم بهصورت چرخهای راهاندازی مجدد میکند هم میتواند اتصال VNet به Web App را قطع کند، و این شکست در سمت پلتفرم است نه در پیکربندی کلاینت. نشانه این است که آیا قطع از یک فاصله ثابت پیروی میکند یا از تغییری که شما دادهاید.
سه شیء و مقادیرشان را در یک سابقه نگه دارید: فضای نشانی شبکه مجازی، فهرست پیشوندهای دروازه شبکه محلی، و ارجاع کلید مشترک اتصال. مقاله PowerShell سایتبهسایت فرمانهای دروازه شبکه محلی و ترتیبی را که به آن تعلق دارند مستند میکند. مقایسه یک تغییر پیشوند با حافظه همان روشی است که یک تونل سالم دو بار بازسازی میشود.
سپس به همان ترتیبی که تغییر دادید بررسی کنید: دروازه شبکه محلی فهرست پیشوند جدید را نشان میدهد، اتصال دوباره Connected است، و شمارندهها وقتی ترافیکی به میزبان در محدوده جدید میفرستید حرکت میکنند. اگر گام سوم شکست بخورد در حالی که دو گام اول میگذرند، سمت دور انتخابگر ترافیک جدید را نپذیرفته و دستگاه دور به ورودی مرحله 2 متناظر نیاز دارد. این گفتوگویی با سر دیگر تونل است، نه تغییری دیگر در Azure.