OpenVPN TUN در برابر TAP: سه شرطی که تصمیم میگیرد
یکی از رابطها بستههای IP را حمل میکند و دیگری فریمهای Ethernet را. پیش از پل زدن هر چیزی، برنامه، پشتیبانی کلاینت و نشانه واقعی را بررسی کنید.
دو تونل میتوانند همان انتقال فایل را حمل کنند و در آنچه روی سیم میگذارند کاملاً متفاوت باشند. یکی بستههای IP را میان دو نشانی جابهجا میکند و دیگری فریمهای Ethernet را جابهجا میکند و میتواند به یک قطعه شبکه پل شود. همین تفاوت تعیین میکند کدام برنامهها کار میکنند، کدام کلاینتها میتوانند متصل شوند و چه مقدار طراحی شبکه را میپذیرید.
سه شرط در عمل آن را روشن میکند. به ترتیب از آنها بگذرید، چون شرط اول معمولاً بحث را پایان میدهد.
هر رابط در واقع چه چیزی حمل میکند
دستگاه TUN یک رابط نقطهبهنقطه در لایه 3 است: هسته بستههای IP را به آن میدهد و تونل آنها را به نشانی همتا میبرد. دستگاه TAP یک رابط در لایه 2 است که فریمهای Ethernet را حمل میکند و همین است که پل زدن را ممکن میکند، چنانکه مستندات هسته توصیف میکند. هیچکدام نحوه رمزگذاری داده را تغییر نمیدهد و هیچکدام تنظیم قدرت نیست. انتخاب درباره چیزی است که دو سر باید مبادله کنند، نه درباره اینکه ترافیک چقدر خوب محافظت میشود.
یک پیامد بیدرنگ دنبال میآید: هر دو سر باید همنظر باشند. کلاینتی که برای یک نوع دستگاه پیکربندی شده نمیتواند به سروری که برای نوع دیگر پیکربندی شده بپیوندد، هر چیز دیگری که همخوان باشد.
شرط اول: آیا چیزی به لایه دو نیاز دارد؟
پل زدن پیچیدگی خود را زمانی سزاوار میشود که یک پروتکل واقعاً به همان دامنه پخش نیاز داشته باشد: ترافیک غیر IP، کشفی که نمیتواند از یک مسیریاب بگذرد، یا برنامهای که اصرار دارد در یک قطعه باشد. هر چیز دیگری مسئله مسیریابی است و مسیریابی آن را با ساز و کار بسیار کمتری حل میکند. گسترش یک قطعه در یک ناحیه بزرگ گسترش پخشهای آن را هم به دنبال دارد، پس جلوگیری از حلقه، برنامهریزی نشانی و دامنههای خرابی همه بخشی از طراحی میشوند. این برای شرطی که یک مسیر تنها برآورده میکرد، پذیرفتن زیادی است.
آزمون مشخص است: برنامهای را که روی تونل مسیریابیشده شکست میخورد نام ببرید و بگویید چرا. اگر پاسخ این است که به پخش نیاز دارد، لایه دو پاسخ صادقانه است. اگر پاسخ این است که کسی نمیتوانست به یک سرور برسد، شرط یک مسیر یا یک قاعده دیوار آتش است.
شرط دوم: آیا کلاینتها میتوانند؟
پشتیبانی یکسان نیست. کلاینتهای رومیزی معمولاً هر دو نوع دستگاه را عرضه میکنند، در حالی که کلاینتهای همراه و نهفته اغلب تنها حالت مسیریابیشده را پیاده میکنند، و نمایهای که بیاعتراض وارد میشود هنوز میتواند هنگام تلاش برای ساختن رابط شکست بخورد. کلاینت و نسخه مشخص را بررسی کنید نه اینکه مجموعه امکانات را از نام سکو استنتاج کنید.
خطای گزینه پشتیبانینشده دعوتی نیست به پاک کردن خطوط ناآشنا تا زمانی که ورود موفق شود. معنیاش این است که نمایه و کلاینت درباره آنچه ممکن است همنظر نیستند و تعمیر به عهده اپراتوری است که نمایه را صادر کرده. حذف یک گزینه برای ساکت کردن یک اعتبارسنج میتواند اتصالی بسازد که کار میکند به نظر میرسد و در سکوت ویژگیای را حذف میکند که برای آن وجود داشت.
شرط سوم: آیا این واقعاً پرسشی درباره رابط است؟
دو انتخاب مجاور برای مشکلات رابط سرزنش میشوند. دستگاه مجازی تعیین میکند چه چیزی وارد تونل میشود، در حالی که UDP یا TCP تعیین میکند که انتقال بیرونی چگونه رفتار کند، و هیچکدام انتقالهایی را که متوقف میشوند درمان نمیکند. وقتی انتقالهای بزرگ معلق میمانند در حالی که کوچکها موفق میشوند، اندازه بسته و MTU سزاوار توجه هستند.
کلاینتی که متصل میشود و بعد نمیتواند به یک میزبان داخلی برسد معمولاً به مسیریابی، یک قاعده دیوار آتش یا مسیر برگشت گمشده نگاه میکند.
برای یک سرویس مدیریتشده از آرایش رابطی که نمایه اپراتور مشخص میکند استفاده کنید، چون سمت سرور از پیش حول آن ساخته شده است. برای استقرار خصوصی از شرط واقعی برنامه انتخاب کنید و دلیل را کنار انتخاب بنویسید.
پرسش این نیست که کدام گزینه قویتر است. این است که ترافیک واقعاً به کدام نیاز دارد.