یک درگاه OpenVPN، سه سرویس: چرا درگاه‌های داخلی اهمیت دارند

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

جریان بیرونی چه چیزی را حمل می‌کند و چه چیزی را پنهان

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

بنابراین یک ضبط روی رابط WAN یک گفت‌وگو نشان می‌دهد، نه سه. درگاه‌های داخلی فقط پس از کپسول‌زدایی ظاهر می‌شوند. به همین دلیل یک بازشدگی دیوار آتش می‌تواند هم‌زمان SSH، HTTPS و DNS را حمل کند.

# WAN side: one outer tuple, whatever the inner services are
tcpdump -ni wan0 'udp port 443'
# tunnel side: the inner tuples appear after decapsulation
tcpdump -ni tun0

مستندات TUN/TAP تحویلی را پوشش می‌دهد که در آن یک دستگاه TUN مسیریابی‌شده بسته‌های IP را میان هسته و فرآیندی در فضای کاربر جابه‌جا می‌کند. همین تحویل است که سرآیک داخلی را برای کد مسیریابی و دیوار آتش دروازه مرئی می‌کند. همچنین توضیح می‌دهد چرا درگاه بیرونی چیزی درباره سرویس‌های مجاز نمی‌گوید.

فرستادن NAT به شنونده تعلق دارد، نه به برنامه‌ها

یک دروازه خودمیزبان پشت NAT منطبق بر IPv4 به یک ترجمه ورودی نیاز دارد: نشانی و درگاه عمومی به شنونده VPN نگاشت می‌شوند. هیچ قاعده‌ای برای SSH، HTTPS یا DNS صرفاً چون کاربران تونل به آن‌ها می‌رسند لازم نیست. انتشار آن درگاه‌ها سرویس‌هایی را آشکار می‌کرد که تونل از قبل از آن‌ها محافظت می‌کند. قاعده فرستادن دسترسی‌پذیری شنونده را توصیف می‌کند، نه مجوزی برای چیزی در درون.

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

سیاست داخلی همان جایی است که دسترسی واقعاً تعیین می‌شود

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

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

dig @10.40.0.53 app.corp.example
nc -vz 10.40.0.10 8443
ssh -p 2222 [email protected]

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

WireGuard همان مرز را می‌کشد

WireGuard شنونده بیرونی خود را با ListenPort نام می‌برد، و یک برنامه داخلی همچنان از هر درگاه سرویسی که لازم دارد استفاده می‌کند. AllowedIPs مجموعه‌ای از پیشوندهای مسیریابی‌شده است، نه فهرستی از درگاه‌های سرویس مجاز. خواندن آن به‌عنوان فهرست مجاز درگاه‌ها قواعدی می‌سازد که با کاری که تونل انجام می‌دهد نمی‌خواند. نام‌گذاری متفاوت است؛ لایه‌بندی نه.

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

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