OpenVPN iroute در برابر مسیر هسته: کدام گم شده است؟

یک بسته برای 10.77.20.0/24 دو تصمیم جداگانه روی سرور OpenVPN می‌گیرد: سیستم‌عامل باید آن را به رابط VPN تحویل دهد، و OpenVPN باید بداند کدام کلاینت متصل مالک آن پیشوند است. مسیر هستهٔ گمشده بسته را پیش از تونل دور می‌ریزد، و مسیر همتای گمشده آن را پس از تونل دور می‌ریزد. این دو خرابی از LAN دور یکسان به نظر می‌رسند و تشخیص اینکه کدام را دارید در هر طرف یک فرمان می‌خواهد.

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

دو تصمیم، نه یک مسیر

پیوندی از سایت به سایت را تصور کنید که 10.77.20.0/24 پشت یک کلاینت تنها قرار دارد. مسیر هستهٔ سرور، برای نمونه ip route add 10.77.20.0/24 dev tun0، بسته‌های منطبق را به دستگاه تونل می‌فرستد. سپس OpenVPN جدول درونی خودش را که از ورودی‌های iroute در پوشهٔ پیکربندی کلاینت ساخته شده بررسی می‌کند تا تصمیم بگیرد کدام اتصال همتا آن‌ها را دریافت می‌کند. بدون مسیر هسته بسته هرگز به فرایند نمی‌رسد، و بدون مسیر همتا به فرایند می‌رسد و به جایی نمی‌رود.

این تفکیک آسان فراموش می‌شود، چون یک خط مسیر در نمایهٔ کلاینت می‌تواند چنین به نظر برسد که هر دو کار را انجام می‌دهد. انجام نمی‌دهد: فرستادن مسیر به کلاینت‌ها می‌گوید چه چیزی را از تونل بفرستند، در حالی که iroute به سرور می‌گوید محدودهٔ نشانی پشت یک کلاینت از کیست. این دو در پرونده‌های مختلف زندگی می‌کنند، از دو طرف مختلف خوانده می‌شوند و در جهت‌های مخالف شکست می‌خورند.

iroute کجا می‌نشیند و چه می‌گوید

این ورودی در پرونده‌ای برای هر کلاینت به نام common_name آن کلاینت، زیر client-config-dir، به شکل iroute 10.77.20.0/24 قرار می‌گیرد. تطابق نام پرونده ظاهری نیست: OpenVPN هویت احرازشده را جستجو می‌کند و پرونده را دقیقاً با همان نام می‌خواند، پس پرونده‌ای به نام site-a تنها برای کلاینتی اثر دارد که نام عمومی‌اش site-a باشد. اگر کلاینت‌های بدون چنین پرونده‌ای باید کاملاً رد شوند، ccd-exclusive را اضافه کنید، که وقتی هر کلاینت یک دروازهٔ سایت است تنظیم درست همین است. برای هر دروازه یک پرونده نگه دارید و آن را به نام موضوع گواهی‌ای که واقعاً صادر می‌کنید نام‌گذاری کنید.

پیش از متهم کردن LAN دور، ورودی را از سرور بیازمایید. پروندهٔ وضعیت کلاینت‌های متصل را با نام‌های عمومی‌شان فهرست می‌کند، و سروری که با --verb 4 اجرا می‌شود نصب iroute را در لحظهٔ اتصال همتا ثبت می‌کند. اگر هنگام اتصال چیزی ظاهر نشد، پرونده در پوشهٔ اشتباه است یا هویت اشتباه را نام می‌برد.

تله: پرونده هست، هویت اشتباه است

یک iroute درست‌نما که به همتای اشتباه وصل شده بیش از پروندهٔ گمشده وقت تلف می‌کند، چون همه چیز روی دیسک درست به نظر می‌رسد. تغییر نام گواهی‌ها، نام‌های عمومی تکراری و username-as-common-name که هویت مؤثر را تغییر می‌دهد همه این را تولید می‌کنند. بررسی کنید سرور کدام هویت را احراز کرده، نه کدام را انتظار داشتید: خروجی وضعیت معتبر است، در حالی که نام پرونده فقط یک کلید جستجو است.

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

مسیر را فراتر از همتا کامل کنید

مالکیت همتا میانهٔ مسیر است، نه پایان آن. کلاینت باید بسته‌ها را از تونل به LAN خودش هدایت کند، یعنی ارسال IP روی آن میزبان فعال باشد و قاعده‌ای در دیوار آتش عبور را مجاز کند. میزبان‌های LAN دور به مسیر بازگشتی برای نشانی تونل نیاز دارند: یا مسیری که به دروازه برگردد، یا طراحی عامدانهٔ NAT در سمت کلاینت. تنظیم ارسال را روی کلاینت با sysctl net.ipv4.ip_forward تأیید کنید، نه با فرض پیش‌فرض توزیع.

اگر کلاینت‌های VPN دیگر باید به آن زیرشبکه برسند، ترتیب دوباره بزرگ‌تر می‌شود: سرور به client-to-client نیاز دارد و آن کلاینت‌ها باید پیشوند را از تونل مسیریابی کنند. هیچ‌یک از این‌ها از جدول مسیر خود سرور برنمی‌آید.

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