وقتی VPN روشن است، فایروال ابری کدام نشانی را می‌بیند
تونل کامل نشانی مبدأیی را که پایگاه داده شما می‌بیند تغییر می‌دهد. فهرست مجاز، مسیر خصوصی یا تونل تقسیم‌شده را جابه‌جا کنید، نه اعتبارنامه را.
پایگاه داده‌ای که پیش از اتصال VPN کار می‌کند و پس از آن شکست می‌خورد، به‌ندرت مشکل اعتبارنامه است. فایروال‌های ابری نشانی‌های مبدأ را تطبیق می‌دهند و تونل کامل همان نشانی را که با آن تطبیق می‌دادند جایگزین می‌کند. فاصله میان آنچه فکر می‌کنید لپ‌تاپ شما می‌فرستد و آنچه سرور دریافت می‌کند همان کل باگ است و در یک گام قابل اندازه‌گیری است.
نشانی مبدأ به چه چیزی تبدیل می‌شود
در تونل کامل، هر بسته از دروازه VPN خارج می‌شود، بنابراین سرور نشانی خروج دروازه را می‌بیند نه اتصال خانگی شما را. اگر پراکسی پیشرو در مسیر باشد، نشانی آن می‌رسد. هر دو مبدأهای مشروعی هستند و هیچ‌یک نشانی موجود در قاعده اصلی شما نیست.
قواعد فایروال Azure SQL در سطح سرور و سطح پایگاه داده، نشانی کلاینتی را که به سرور منطقی می‌رسد تطبیق می‌دهند که پس از تونل کامل همان نشانی خروج است. گروه امنیتی AWS که یک نشانی را مجاز می‌کند به همین شکل رفتار می‌کند. بسته پیش از احراز هویت کنار گذاشته می‌شود، بنابراین خطایی که دریافت می‌کنید شبیه خرابی شبکه است نه مشکل مجوز. دقیقاً به همین دلیل است که مردم شروع به بازنشانی گذرواژه‌ها می‌کنند.
فهرست مجاز کجا تعیین می‌شود
قاعده‌ای را بخوانید که با مسیر ناموفق تطبیق دارد، نه قاعده‌ای را که به یاد دارید ساخته‌اید. به دامنه، پورت، پروتکل و اینکه آیا پیش از هر بررسی هویت ارزیابی می‌شود توجه کنید.
سپس تصمیم بگیرید کدام لایه به‌طور مشروع مالک این تصمیم است. قاعده نشانی پاسخ می‌دهد که ترافیک از کجا می‌آید. نقطه پایانی خصوصی پاسخ می‌دهد که آیا سرویس اصلاً از مسیر خصوصی در دسترس است. استثنای تونل تقسیم‌شده پاسخ می‌دهد کدام مقصدها تونل را دور می‌زنند. این‌ها قابل تبادل نیستند و هر یک هنگام تغییر تونل به شکلی متفاوت شکست می‌خورد.
سه تعمیر، سه لایه
هر گزینه زیر جریان را به دلیلی متفاوت درست می‌کند و انتخاب گزینه نادرست اتصالی می‌سازد که تا تغییر بعدی دروازه کار می‌کند.
| Repair | Layer it changes | What it does not fix |
|---|---|---|
| Add the egress address to the rule | Source address matching | Nothing about routing, and it breaks when the egress moves |
| Use a private endpoint | Whether the service is reached privately | A client that still resolves the public name |
| Add a split-tunnel exception | Which flows bypass the tunnel | An expired credential or a wrong password |
افزودن نشانی خروج کوچک‌ترین تغییر و شکننده‌ترین آن است، چون دروازه جدید یا منطقه‌ای دیگر آن را بی‌صدا بی‌اعتبار می‌کند. نشانی را کنار تعریف تونل مستند کنید تا هر دو با هم جابه‌جا شوند. محدوده گسترده موقت یک تشخیص است نه تعمیر؛ باقی گذاشتن آن همان راهی است که سرویس‌های داخلی در نهایت افشا می‌شوند.
چرا یک پلتفرم مدیریت‌شده نمی‌تواند به تونل بپیوندد
پلتفرم‌های برنامه‌ای مانند Heroku، AppHarbor یا CloudBees کد شما را در محیطی بدون دستگاه tun یا tap و بدون اختیار ساختن یکی اجرا می‌کنند. مدل ورودی آن‌ها HTTP است نه یک سوکت شنود دلخواه. یک buildpack که یک باینری VPN حمل می‌کند هنوز جایی برای قرار دادن واسط ندارد. الگوهای عملی عبارت‌اند از نشانی خروج ثابتی که پایگاه داده بتواند مجاز کند، محصول اتصال خصوصی که پلتفرم ارائه می‌دهد، یا پراکسی در DMZ که از طریق HTTPS به آن می‌رسند.
همان پراکسی مسیری دسترسی با احراز هویت و ثبت لاگ خودش است. پلتفرم را عضو VPN شما نمی‌کند و توصیف آن به این شکل قواعدی می‌سازد که هیچ‌کس نمی‌تواند حسابرسی کند.
از کلاینتی که شکست خورد بررسی کنید
دوباره وصل شوید و مسیر دقیق کلاینت را تکرار کنید. نشانی مبدأ که سرویس ثبت می‌کند، مسیری که کلاینت برای نام پایگاه داده انتخاب می‌کند و نتیجه پرس‌وجوی واقعی را به همین ترتیب بررسی کنید. آزمایش از دروازه اثبات می‌کند که دروازه کار می‌کند، چیزی که هرگز زیر سؤال نبود. اگر اتصال اکنون احراز هویت می‌شود و پرس‌وجو هنوز شکست می‌خورد، مشکل باقی‌مانده مجوز پایگاه داده است.
هر زمان تونل تغییر کرد این قواعد را بازبینی کنید. دروازه‌ای جایگزین‌شده یا محدوده خروج جدید مسیر را بدون هیچ تغییری در پیکربندی برنامه می‌شکند.