شبکه‌هایی که فقط TCP 443 را مجاز می‌کنند در کنار شبکه‌هایی وجود دارند که UDP را راحت عبور می‌دهند، و یک سرور باید به هر دو خدمت دهد. پروفایلی با proto udp به گروه دوم پاسخ می‌دهد و در گروه اول شکست می‌خورد، و ویرایش همان پیکربندی برای گفتن proto tcp شنونده دومی نمی‌سازد. این دستور یک ترابری را برای یک فرایند انتخاب می‌کند. هر چیز دیگری از همین محدودیت نتیجه می‌شود.

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

پیش از 2.7 یک فرایند یک ترابری را مقید می‌کند

نسخهٔ اجتماعی OpenVPN سوکتی را که proto توصیف می‌کند مقید می‌کند، و آن دستور یک ترابری واحد را برای نمونه انتخاب می‌کند. TCP و UDP پشته‌های جداگانه‌اند، پس یک شمارهٔ پورت می‌تواند همزمان توسط هر دو اشغال شود، اما نه توسط یک فرایند. بنابراین خط 2.6 به شما یک ترابری برای هر دیمن می‌دهد. OpenVPN 2.7 این محدودیت را برای سرورها برداشت، که می‌توانند چند سوکت را با چند --local در یک فرایند مقید کنند.

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

سه راه برای اجرای دو نمونه

با رابط‌های TAP، برای هر ترابری یک نمونه اجرا کنید و دو دستگاه tap را روی میزبان پل کنید. هر دو مجموعهٔ کارخواه در یک دامنهٔ پخش قرار می‌گیرند، که به یک استخر آدرس اجازه می‌دهد آن‌ها را بپوشاند و پروتکل‌های وابسته به پخش را فعال نگه می‌دارد. با TUN پل‌سازی در دسترس نیست، پس ساده‌ترین تقسیم به هر نمونه زیرشبکهٔ خودش را می‌دهد و مسیریابی دو مجموعهٔ کارخواه را جدا نگه می‌دارد. گزینهٔ سوم یک استخر را نگه می‌دارد، به این صورت که هر نمونه یک اسکریپت learn-address را فراخوانی می‌کند که مسیر /32 را برای کارخواه از طریق دستگاه همان نمونه نصب می‌کند.

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

ArrangementInterfacesAddress poolCost
Bridged TAP pairTwo tap devices joined by a bridgeOne shared poolBroadcast traffic and bridge maintenance
Two TUN subnetsTwo tun devices, no bridgeOne pool per instanceRouting rules and two plans
Shared pool with routesTwo tun devices plus a hookOne pool across bothA script on the data path

دو نمونه را جدا نگه دارید

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

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

پروفایل را با شنونده تطبیق دهید

سروری که proto tcp را اجرا می‌کند پروفایل کارخواهی با proto tcp-client انتظار دارد، و پروفایلی که هنوز proto udp را در برابر آن شنونده حمل می‌کند بدون خطایی که کاربر بتواند روی آن عمل کند به پایان مهلت می‌رسد . اگر استقرار هر دو ترابری را ارائه می‌دهد دو پروفایل نگه دارید و آن‌ها را برچسب بزنید تا پشتیبانی بفهمد کدام آزمایش شده است. شمارهٔ پورت به‌تنهایی ترابری را توصیف نمی‌کند.

قواعد فایروال همان تقسیم را دنبال می‌کنند: قاعده‌ای برای UDP 1194 چیزی دربارهٔ TCP 1194 نمی‌گوید، و قاعده‌ای برای یک آدرس شنوندهٔ دیگر را پوشش نمی‌دهد.

اول دیدگاه سرور را بخوانید

با ss -lntup روی سرور شروع کنید و تأیید کنید که هم شنوندهٔ TCP و هم UDP ظاهر می‌شوند. سپس از هر نوع یک کارخواه وصل کنید و خروجی وضعیت را برای دو ورودی با آدرس‌های متفاوت بررسی کنید. اگر سوکت‌ها وجود دارند و هیچ کارخواهی نمی‌رسد، مسیر یا فایروال بسته‌ها را پیش از دیدن دیمن رد می‌کند.

سوکتی که هرگز ظاهر نمی‌شود مشکلی در پیکربندی یا مقیدسازی است، و سوکتی که ظاهر می‌شود اما هرگز اتصالی ثبت نمی‌کند مشکلی در فیلترکردن است. از دید کارخواه این دو یکسان به نظر می‌رسند، به همین دلیل دید خود سرور اول می‌آید. به یاد داشته باشید که TCP مسدودسازی سر صف را حمل می‌کند، پس ارائهٔ آن اقدامی برای دسترس‌پذیری است نه ارتقا برای کارخواهانی که مسیر UDP پاکی دارند.

مقالات مرتبط