مسیریابی کلاینت‌های OpenVPN از طریق Cloudflare؟ ابتدا نقش را بررسی کنید
کلاینت دستگاه یک روتر نیست. تأیید کنید که نقش Cloudflare بسته‌های میزبان‌های دیگر را ارسال می‌کند، سپس تونل خود سرور را در مسیر قدیمی‌اش نگه دارید.
شما یک سرور OpenVPN کارآمد و میزبانی دارید که نرم‌افزار دستگاه Cloudflare را نیز اجرا می‌کند، و قدم بعدی بدیهی به نظر می‌رسد که ترافیک کلاینت‌ها را به سمت آن هدایت کنید. دو اتصال کارآمد روی یک ماشین با هم یک دروازه ترانزیت نمی‌سازند. آنچه کم است نقشی است که به‌طور مستند بسته‌های متعلق به دیگری را ارسال کند، و سیاستی که آن بسته‌ها را هنگام ورود طبقه‌بندی کند.
پیش از هر قاعده‌ای چهار پرسش مطرح است: چه ترافیکی وارد می‌شود، بعد کجا می‌رود، پاسخ‌ها چگونه راه بازگشت را پیدا می‌کنند، و طراحی وقتی آن مسیر دوم از کار می‌افتد چه می‌کند. دو پرسش نخست پرسش‌های توانایی هستند.
دو سرویس روی یک میزبان مسیر ترانزیت نیستند
کلاینت دستگاه ساخته شده است تا ترافیکی را مدیریت کند که روی همان ماشینی که اجرا می‌شود تولید می‌شود. این نرم‌افزار تفکیک نام یا ترافیک برنامه‌های انتخاب‌شده را رهگیری می‌کند و آن را از تونل خودش می‌فرستد، و سیاستش برای کاربر همان دستگاه و فرایندهای همان دستگاه نوشته شده است. بسته‌ای که از کلاینت OpenVPN ارسال می‌شود خروجی محلی نیست، پس همان قواعد آن را طبقه‌بندی نمی‌کنند. این یک جزئیات پیکربندی نیست که بتوان با قاعده‌ای گسترده‌تر پوشاند، چون تعیین می‌کند که آیا نرم‌افزار اصلاً بسته را می‌بیند یا نه.
به همین دلیل پرسش طراحی یک پرسش توانایی است. یا محصول نصب‌شده نقشی مستند برای ارسال ترافیک شبکه‌های دیگر دارد، یا کارکرد ترانزیت کاملاً به جای دیگری تعلق دارد.
کدام نقش Cloudflare اجازه ارسال دارد
کلاینت دستگاه Cloudflare حالت‌هایی با دامنه‌های متفاوت ارائه می‌دهد: فقط تفکیک نام، ترافیک از دستگاه، و گاهی هر دو. هیچ‌یک از این حالت‌ها میزبان را به روتری برای یک محدوده خصوصی که از تونل دیگری می‌آید تبدیل نمی‌کند. نقش مسیریابی اختصاصی محصولی جداگانه با کانکتور، ثبت‌نام و مدل شبکه خودش است.
| Question | What has to answer it |
|---|---|
| Does the installed product forward packets from other hosts? | A documented routing or connector role, not a device mode |
| Which prefixes does the connector advertise? | Its own configuration and status output |
| Does the server's own transport still take the old path? | ip route get for the endpoint, before and after |
| Do replies return through the same path? | Connection tracking counters on the forward rule |
پیش از طراحی مسیرها حول آن، نقش نصب‌شده را بررسی کنید. بخوانید کانکتور کدام واسط را می‌سازد، آیا پیشوندهای مشخص یا مسیر پیش‌فرض را اعلام می‌کند، و آیا سیاست محلی بر بسته‌های ارسال‌شده همانند بسته‌های محلی اعمال می‌شود. اگر فقط ترافیک محلی مدیریت شود، سرور OpenVPN نمی‌تواند نقطه ترانزیت باشد، هر طور که قاعده ترجمه نوشته شود.
اینجا همان‌جایی است که الزام خروج عمومی باید دقیق بیان شود. خروجی که Cloudflare برای ترافیک ارسال‌شده کلاینت‌ها فراهم می‌کند یک مورد استفاده مشخص است و باید در برابر سرویسی که واقعاً دارید تأیید شود.
تونل بیرونی را مستقل از مسیر جدید نگه دارید
همان لحظه که یک مسیر پیش‌فرض به سمت واسط جدید اضافه می‌کنید، ترافیک خروجی خود سرور برای آن رقابت را آغاز می‌کند، و این شامل پاسخ به کلاینت‌های OpenVPN و نشست SSH شما به آن جعبه هم می‌شود. نشانه معمول تونلی است که برقرار می‌شود و سپس می‌میرد، یا مدیری که بیرون قفل می‌شود در حالی که به نظر می‌رسد تغییر کار کرده است. برای نقطه پایانی، ip route get را قبل و بعد مقایسه کنید، و از مسیریابی سیاست‌محور یا یک مسیر میزبان استفاده کنید تا انتقال خود سرور را در همان جایی که بود نگه دارید. این مقایسه را از خود جعبه اجرا کنید، چون دید سرور نسبت به مسیر خودش همان چیزی است که اهمیت دارد.
استثنا برای نشانی عمومی سرور به‌تنهایی کافی نیست، چون مسیر بازگشت هر مدیر راه دور جریانی متفاوت است. تصمیم بگیرید کدام یک از این جریان‌ها باید از تغییر جان سالم به در ببرد، سپس هر یک را بررسی کنید به‌جای اینکه فرض کنید اولی بقیه را پوشش می‌دهد.
ارسال و ترجمه را به یک جریان محدود کنید
بسته‌های دریافت‌شده از مسیر ارسال پیروی می‌کنند، نه از مسیر خروجی محلی، پس قاعده‌ای که اهمیت دارد در قلاب forward زندگی می‌کند. جایی که واسط بعدی به ترجمه نیاز دارد، مبدأ را به مجموعه کلاینت‌ها، مقصد را به آنچه مجاز است و خروجی را به همان یک واسط محدود کنید. قاعده masquerade که فقط به یک واسط گره خورده است، خودش هیچ مسیری انتخاب نمی‌کند و اجازه ارسال از هیچ فیلتر دیگری را نمی‌دهد.
رفتار بسته‌شدن در هنگام شکست را از پیش تعیین کنید، سپس آن را بیازمایید. مسیر بعدی را متوقف کنید و تأیید کنید که کلاینت‌ها خروجی موردنظر را از دست می‌دهند نه اینکه بی‌صدا به پیوند بالادست معمولی برگردند، چون این همان نتیجه‌ای است که هیچ‌کس متوجهش نمی‌شود تا وقتی ترافیک از در اشتباه خارج شود. بررسی را برای تفکیک نام و IPv6 تکرار کنید، چون مجموعه قواعد فقط برای v4 مسیر v6 را باز می‌گذارد.
چهار پاسخ را که بر آن‌ها مستقر شدید و مشاهده‌ای را که هر یک را نشان می‌دهد بنویسید. مسیر ترانزیتی که می‌توانید توصیف کنید همانی است که در بازبینی حوادث بعدی می‌توانید از آن دفاع کنید.