ارائه OpenVPN روی TCP و UDP از یک میزبان
پیش از 2.7 هر فرایند یک ترابری را مقید میکند. جفت TAP پلشده، دو زیرشبکه TUN و یک استخر مشترک را مقایسه کنید، سپس هر پروفایل را با شنوندهاش تطبیق دهید.
شبکههایی که فقط 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 را برای کارخواه از طریق دستگاه همان نمونه نصب میکند.
همین چیدمان سوم است که مردم میخواهند و همان است که بیشترین دقت را میطلبد، زیرا اسکریپت بخشی از مسیر داده میشود و باید رویدادهای افزودن، بهروزرسانی و حذف را درست پردازش کند.
| Arrangement | Interfaces | Address pool | Cost |
|---|---|---|---|
| Bridged TAP pair | Two tap devices joined by a bridge | One shared pool | Broadcast traffic and bridge maintenance |
| Two TUN subnets | Two tun devices, no bridge | One pool per instance | Routing rules and two plans |
| Shared pool with routes | Two tun devices plus a hook | One pool across both | A script on the data path |
دو نمونه را جدا نگه دارید
هر نمونه هم به پورت یا آدرس جداگانه، فایل وضعیت جداگانه و مقصد گزارش جداگانه نیاز دارد. دو دیمن که به یک فایل وضعیت میافزایند خروجیای میسازند که در هنگام یک حادثه خواندنی نیست، و دقیقاً همان وقت به آن نیاز دارید. اگر نمونهٔ دوم آدرس مشخصی را مقید کند، آن آدرس باید هنگام شروع فرایند روی میزبان وجود داشته باشد؛ وگرنه با خطای مقیدسازی خارج میشود پیش از آنکه چیزی دربارهٔ کلیدها بگوید.
واحدها و پروفایلها را طوری نامگذاری کنید که ترابری از نام فایل آشکار باشد . اپراتور بعدی نباید مجبور شود پیکربندی را باز کند تا بفهمد کدام TCP است.
پروفایل را با شنونده تطبیق دهید
سروری که proto tcp را اجرا میکند پروفایل کارخواهی با proto tcp-client انتظار دارد، و پروفایلی که هنوز proto udp را در برابر آن شنونده حمل میکند بدون خطایی که کاربر بتواند روی آن عمل کند به پایان مهلت میرسد . اگر استقرار هر دو ترابری را ارائه میدهد دو پروفایل نگه دارید و آنها را برچسب بزنید تا پشتیبانی بفهمد کدام آزمایش شده است. شمارهٔ پورت بهتنهایی ترابری را توصیف نمیکند.
قواعد فایروال همان تقسیم را دنبال میکنند: قاعدهای برای UDP 1194 چیزی دربارهٔ TCP 1194 نمیگوید، و قاعدهای برای یک آدرس شنوندهٔ دیگر را پوشش نمیدهد.
اول دیدگاه سرور را بخوانید
با ss -lntup روی سرور شروع کنید و تأیید کنید که هم شنوندهٔ TCP و هم UDP ظاهر میشوند. سپس از هر نوع یک کارخواه وصل کنید و خروجی وضعیت را برای دو ورودی با آدرسهای متفاوت بررسی کنید. اگر سوکتها وجود دارند و هیچ کارخواهی نمیرسد، مسیر یا فایروال بستهها را پیش از دیدن دیمن رد میکند.
سوکتی که هرگز ظاهر نمیشود مشکلی در پیکربندی یا مقیدسازی است، و سوکتی که ظاهر میشود اما هرگز اتصالی ثبت نمیکند مشکلی در فیلترکردن است. از دید کارخواه این دو یکسان به نظر میرسند، به همین دلیل دید خود سرور اول میآید. به یاد داشته باشید که TCP مسدودسازی سر صف را حمل میکند، پس ارائهٔ آن اقدامی برای دسترسپذیری است نه ارتقا برای کارخواهانی که مسیر UDP پاکی دارند.