دو IP عمومی روی یک VM ویپیان Azure: هر کدام چه کاری میکند

داشتن دو IP عمومی روی یک VM ویپیان Azure انتظاری میسازد که بهندرت برآورده میشود: نشانیای که مشتریان به آن وصل میشوند همان نشانیای خواهد بود که وبسایتها میبینند. سه تصمیم مستقل این نتیجه را میسازند و تنها اولی درباره شنونده تونل است. دومی منبع مهمان است که برای ترافیک مشتری فورواردشده استفاده میشود و سومی روش خروج Azure است که بر آن منبع اعمال میشود. یکی را تغییر دهید و دو تای دیگر سر جای خود میمانند، پس هر یک را صریح تصمیم بگیرید.

تصمیم 1: تونل کجا پایان مییابد

یک IP عمومی Azure به یک پیکربندی IP خصوصی روی NIC متصل است؛ نشانیای نیست که داخل سیستمعامل مهمان اضافه کنید. نگاشت را بخوانید نه اینکه فرض کنید: az network nic show --ids /subscriptions/.../networkInterfaces/vpn-nic --query 'ipConfigurations[].{private:privateIPAddress,public:publicIPAddress.id}'. هر نشانی خصوصیای که آن پرسوجو برگرداند، همان است که مهمان باید واقعاً داشته باشد.

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

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

تصمیم 2: مشتری فورواردشده از چه منبعی استفاده میکند

پس از آنکه دروازه درخواست مشتری را رمزگشایی کرد، بستهای که فوروارد میکند با بستهای که به شنونده VPN رسیده متفاوت است. مهمان به فورواردینگ فعال، سیاست فایروالی که جریان را مجاز کند و نشانی منبعی که طراحی ابر اجازه میدهد نیاز دارد. اگر نشانی داخلی مشتری را ترجمه کنید، همان منبع ترجمهشده است که Azure ارزیابی میکند، نه نشانی داخلی مشتری.

یک قاعده باریک SNAT میتواند منبع خصوصی مهمان را انتخاب کند، اما نمیتواند بر ترجمه بعدی Azure غلبه کند. وقتی به پاسخگویی بهازای هر مشتری داخل VM نیاز دارید SNAT را انتخاب کنید؛ وقتی طراحی خروج زیرشبکه از قبل منبع عمومی پایدار میدهد و ترجمه دوم فقط وضعیت اضافه میکند، از آن صرفنظر کنید.

تصمیم 3: کدام روش خروج Azure برنده میشود

مایکروسافتترتیب اولویت خروجرا مستند میکند: مسیر قابل اعمال به یک دستگاه یا دروازه اولویت دارد و اتصال زیرشبکه از طریق NAT Gateway بر IP عمومی سطح نمونه در مسیر مربوطه اولویت دارد. همین ترتیب دلیل آن است که ترجمه به 10.20.0.5 ثابت نمیکند وبسایتی 198.51.100.20 را میبیند. جدول مسیر مؤثر، ارتباط NAT Gateway و IP عمومی NIC را با هم بخوانید پیش از آنکه طراحی خروج را بپذیرید.

تنظیمفورواردینگ NIC در Azureرا از فورواردینگ لینوکس جدا نگه دارید. پرچم ابر بستههایی را مجاز میکند که منبع یا مقصدشان به NIC تخصیص نیافته است؛ net.ipv4.ip_forward را فعال نمیکند و تنظیم مهمان اجازه ابر را نمیدهد.

سوکت تونل تصمیم منبع خودش را دارد

Address در WireGuard زیر wg-quick نشانیای به رابط WireGuard تخصیص میدهد؛ دستور اتصال UDP بیرونی نیست. منبع سوکت رمزگذاریشده از جدول مسیر پیروی میکند، پس یک مسیر سیاستی یا مسیر پیشفرض دوم میتواند آن را بدون دستزدن به نشانی رابط جابهجا کند.OpenVPN: گزینه local و UDP multihome به همین شکل رفتار میکنند: به شنونده و پاسخهایش مربوطاند نه به منبع اینترنت هر مشتری فورواردشده.

مسیر لایه زیرین که تونل را حمل میکند حفظ کنید و تأیید کنید مشتری هنوز پاسخهای احرازشده را از چیدمان ورود مورد انتظار میگیرد. به ترتیب فهرست نشانیها بهعنوان سیاست دائمی انتخاب منبع تکیه نکنید، زیرا نشانی بعدی که به NIC افزوده شود میتواند تعیین کند کدام برنده است.

چه چیزی را و به چه ترتیبی بپذیریم

سه نتیجه را جداگانه بپذیرید. نخست، یک مشتری بیرونی به ورود VPN مورد نظر میرسد. دوم، درخواست مجاز تازهای از آن مشتری VPN از خروج اینترنت مستند خارج میشود. سوم، مسیرهای ناخواسته شنونده و فورواردینگ ردشده میمانند. نگاشتهای عمومی به خصوصی و مالکان مهمان و ابر هر تصمیم را در یک جا ثبت کنید.

تونل موفق فقط بخش اول را ثابت میکند. خروج را با جریان تازه آزمایش کنید، زیرا یک اتصال کششده میتواند مدت زیادی پس از تغییر مسیر همچنان از منبع قدیمی استفاده کند.