چرا بسیاری از اتصال‌های برنامه‌ها یک نشست OpenVPN را به اشتراک می‌گذارند

یک مرورگر را تصور کنید که صفحه‌ای HTTPS بارگذاری می‌کند، در حالی که یک کلاینت SSH به سرور دیگری می‌رسد و یک حل‌کننده به پرسشی پاسخ می‌دهد، همه از طریق یک نشست OpenVPN. روی رابط فیزیکی یک گفت‌وگو می‌بینید؛ داخل تونل سه گفت‌وگو می‌بینید. هر دو نما درست است، و دانستن اینکه چرا، تفاوت میان یک ثبت مفید و یک ثبت گیج‌کننده است. یک جریان درونی را از سوکت تا سیم دنبال کنید تا لایه‌بندی دیگر انتزاعی نباشد.

یک گفت‌وگوی بیرونی، جریان‌های درونی بسیار

هر برنامه سوکت خودش را باز می‌کند، و هسته به آن یک تاپل پنج‌تایی از نشانی مبدأ، پورت مبدأ، نشانی مقصد، پورت مقصد و پروتکل می‌دهد. این تاپل‌ها پیش از دخالت هر تونلی وجود دارند. سپس مسیریابی تصمیم می‌گیرد که همهٔ آن‌ها از دستگاه تونل خارج شوند، پس بسته‌ای که به OpenVPN سپرده می‌شود هنوز سرآیندهای اصلی را درون خود دارد. OpenVPN آن بستهٔ درونی را رمزگذاری می‌کند و نتیجه را در یک گفت‌وگوی بیرونی UDP یا TCP با همتا می‌پیچد. بنابراین گفت‌وگوی بیرونی یکی است، در حالی که جریان‌های درون آن به تعداد برنامه‌هایی است که باز شده‌اند.

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

پورتی که ثابت می‌ماند

چیزی که ثابت می‌ماند تاپل بیرونی است: نشانی شما، پورت محلی که کلاینت به آن بسته شد، نشانی همتا و پورت سرویس پیکربندی‌شده. همین تاپل است که یک دیوار آتش یا NAT در مسیر باید اجازه دهد، و همین است که یک ثبت روی پیوند بالا نشان می‌دهد. همین هم هست که پس از اتصال دوباره یا تغییر شبکه عوض می‌شود، چون کلاینت ممکن است پورت محلی دیگری بگیرد. یک تونل به معنای یک پورت مبدأ ثابت برای همیشه نیست.

پورت‌های درونی همان چیزی است که برای نقاط پایانی اهمیت دارد. یک جریان HTTPS پورت مقصد 443 را داخل تونل نگه می‌دارد، حتی اگر انتقال بیرونی روی هر پورتی که گرداننده پیکربندی کرده بنشیند. نقاط پایانی برنامه هرگز از پورت بیرونی باخبر نمی‌شوند.

کپسول‌گشایی در طرف دور چه چیزی را تغییر می‌دهد

در همتا لایهٔ بیرونی برداشته می‌شود و بستهٔ درونی باقی می‌ماند. از آنجا به بعد، ارسال و سیاست دسترسی بر مقصد و پروتکل درونی اعمال می‌شود. سرور وب هنوز اتصال HTTPS می‌گیرد، دیمن SSH هنوز SSH می‌گیرد، و حل‌کننده هنوز پرسش می‌گیرد.

به همین دلیل قاعده‌ای که انتقال بیرونی را مجاز می‌کند با قاعده‌ای که یک سرویس درونی را مجاز می‌کند یکی نیست. اولی یک مسیر را توصیف می‌کند؛ دومی یک مجوز را.

TCP بیرونی یعنی یک جریان، نه یک اتصال

وقتی انتقال بیرونی UDP است، سرنوشت هر جریان درونی مستقل است: یک دیتاگرام گم‌شده تا بازفرست خودش بر یک انتقال اثر می‌گذارد. وقتی انتقال بیرونی TCP است، همهٔ جریان‌های درونی یک جریان بایتی مطمئن را شریک می‌شوند.

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

راه‌اندازی خودتان را دقیق توصیف کنید

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

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