یک Pi، دو نمونه OpenVPN: هر واحد چه می‌خواند
دو دیمن OpenVPN روی یک Pi فایل‌های پیکربندی متفاوت می‌خوانند و از قلاب‌های متفاوت خارج می‌شوند. هر نمونه را نقشه کنید، سپس مسیر بار را جداگانه بیازمایید.
پیش از دست زدن به هر پروفایل، فرایندهای OpenVPN را بشمارید. Piای که کاربران سیار را می‌پذیرد و همزمان به یک سرویس بالادست وصل می‌شود، دو دیمن اجرا می‌کند و هر یک فایل پیکربندی‌ای را می‌خواند که با نام نمونه‌ای که تایپ کرده‌اید انتخاب می‌شود. سپس قالب‌های بسته‌بندی‌شده به هر دیمن دایرکتوری کاری خودش، فایل وضعیت زمان اجرای خودش و دستگاه تونل خودش را می‌دهند. اگر این تفکیک را اشتباه کنید، یک شب را صرف تغییر یک تنظیم درست در فایلی می‌کنید که فرایند در حال اجرا هرگز آن را باز نمی‌کند.
هر نام نمونه فایل خودش را انتخاب می‌کند
در فایل‌های واحدی که همراه OpenVPN 2.6 عرضه می‌شوند، آرگومان‌های شروع یک جایگزین‌نگهدار نمونه دارند که از متن پس از نشانه @ پر می‌شود. قالب سرور از دایرکتوری پیکربندی سرور اجرا می‌شود و آرگومان خود را با %i.conf در آنجا تطبیق می‌دهد، در حالی که قالب کلاینت همین کار را از دایرکتوری کلاینت انجام می‌دهد. بنابراین [email protected] فایل admits.conf را در دایرکتوری سرور می‌خواند و [email protected] فایل uplink.conf را در دایرکتوری کلاینت می‌خواند، و هیچ‌یک از این دو نام در دایرکتوری دیگر معنایی ندارد.
تطبیق را روی خود ماشین تأیید کنید، نه اینکه فرض کنید بسته پیش‌فرض‌های بالادست را حفظ کرده است. یک drop-in توزیع مجاز است دایرکتوری کاری یا آرگومان پیکربندی را یکسره جایگزین کند.
systemctl cat [email protected]
systemctl cat [email protected]خط WorkingDirectory و آرگومان پیکربندی را در آن خروجی بخوانید، زیرا واحد فعال‌شده تنها چیزی است که تعیین می‌کند کدام فایل بارگذاری می‌شود. یک drop-in که --config را به ExecStart اضافه می‌کند، حتی وقتی مسیر قالب درست به نظر می‌رسد، بر قالب پیروز می‌شود. وقتی می‌خواهید بدانید آیا بازنویسی محلی در جریان است، مسیرهای قطعه و drop-in را بخواهید. اگر هر دو نقش به یک فایل برسند، یک فرایند دارید که می‌خواهد هم سرور باشد و هم کلاینت، و گزینه بعدی در آن فایل بی‌صدا پیروز می‌شود.
حمل‌ونقل محلی و بار ارسال‌شده به قلاب‌های متفاوت می‌خورند
اتصال رمزگذاری‌شده سرور به هر کاربر سیار روی خود Pi تولید می‌شود، بنابراین پاسخ‌های بیرونی آن از قلاب خروجی محلی خارج می‌شوند. اتصال کلاینت به همتای بالادستش نیز خروجی‌ای است که به‌صورت محلی تولید می‌شود، هرچند به شبکه‌ای دور می‌رسد. بار ارسال‌شده دسته سوم است و هسته فقط پس از آنکه از قبل دستگاه خروجی بسته را انتخاب کرده با آن تطبیق می‌دهد.
| Flow | Hook that sees it | What to inspect |
|---|---|---|
| Roaming user handshakes to the server | Local input and local output | Listener socket, bind address, rule admitting the UDP port |
| User payload leaving through the upstream tunnel | Forward | IPv4 forwarding switch, selected route, permission rule, any translation |
| Pi's own connection to the upstream peer | Local output | Underlay route to the provider endpoint, not the tunnel route |
قاعده‌ای که یک رابط خروجی را درون زنجیره ارسال تطبیق می‌دهد می‌تواند بسته‌ای را مجاز یا حذف کند که مسیریابی از قبل به آن رابط اختصاص داده است، اما هرگز رابط را انتخاب نمی‌کند. وقتی یک میزبان یک تونل را پایان می‌دهد و دیگری را آغاز می‌کند، سیاستی که بار کاربر را به تونل بالادست می‌فرستد و سیاستی که از پاسخ‌های رمزگذاری‌شده خود Pi محافظت می‌کند تصمیم‌های جداگانه‌اند. آنها تصادفاً روی یک کارت شبکه فیزیکی فرود می‌آیند و همین باعث اشتباه گرفتنشان می‌شود.
این تفاوت یک نیم‌شکست رایج را توضیح می‌دهد. کاربران وصل می‌شوند، دست‌دادن کامل می‌شود و ترافیکشان هنوز از راه اشتباه خارج می‌شود، چون دست‌دادن محلی بود و بار ارسال‌شده بود و تنها یکی از این دو هرگز آزموده شده بود.
یک مسیر واردشده می‌تواند پاسخ‌ها به کاربران شما را ببلعد
تنظیم امنیتی پروفایل کلاینت تعیین می‌کند بالادست چه چیزی می‌تواند به جدول مسیریابی Pi هل بدهد، و تغییر مسیر گسترده همان گزینه‌ای است که یک میزبان دو نقشی سالم را به میزبانی خراب تبدیل می‌کند. اگر مسیر هُل‌داده‌شده آدرس‌های عمومی کاربران سیار را بپوشاند، پاسخ‌هایی که سرور برای آنها تولید می‌کند می‌توانند به‌جای خروج از لایه زیرین، مسیر جدید را به درون تونل بالادست دنبال کنند. مردم اغلب تأیید می‌کنند که تونل به سمت ارائه‌دهنده هنوز کار می‌کند و همان‌جا متوقف می‌شوند، چون آن ترافیک حمل‌ونقل خود تونل است و در حالی که همه چیز دیگر بدرفتاری می‌کند، به جریان ادامه می‌دهد.
سیاست مبتنی بر مبدأ یا نشانه همان راهی است که دو جریان جدا می‌مانند. گزینه نشانه لینوکس OpenVPN بسته‌های رمزگذاری‌شده خود دیمن را با یک نشانه دیوار آتش علامت می‌زند که قاعده مسیریابی می‌تواند سپس آن را به جدولی اختصاصی بفرستد. آدرس‌های مبدأ هم به همان خوبی کار می‌کنند وقتی پاسخ‌های بیرونی سرور همیشه از یک آدرس لایه زیرین خارج می‌شوند. هر دو رویکرد به مسیرهای معتبر در جدولی که انتخاب می‌کند و به یک استثنا برای نقطه پایانی ارائه‌دهنده نیاز دارند، وگرنه خود تونل دیگر بالا نمی‌آید.
پیش از نوشتن هر قاعده‌ای از هسته بپرسید یک پاسخ واقعاً چه مسیری را طی می‌کند. آدرس‌های زیر جایگزین‌نگهدار برای یک آدرس لایه زیرین Pi و آدرس عمومی یک کاربر سیار هستند.
ip rule show
ip route get 198.51.100.7 from 192.0.2.10تفکیک را بررسی کنید و سپس نقش‌ها را یکی‌یکی متوقف کنید
سه جریان را جداگانه بیازمایید، چون یک دست‌دادن موفق هیچ چیزی را درباره دو تای دیگر اثبات نمی‌کند. یک اتصال ورودی تازه بپذیرید، یک برنامه مجاز را از خروجی بالادست بفرستید و تأیید کنید که هر دو فرایند همچنان به همتایان خودشان می‌رسند.
سپس نقش کلاینت را متوقف کنید و ببینید نقش سرور چه چیزی را نگه می‌دارد. این ارزان‌ترین راه برای یافتن قاعده مسیر یا نشانه‌ای است که برای یک نمونه در نظر گرفته شده و روی هر دو اعمال شده است.
systemctl stop [email protected]
systemctl status [email protected] --no-pager
ss -lunp | grep openvpn
journalctl -u [email protected] -n 20 --no-pagerچیزی که می‌خواهید ببینید این است که شنونده هنوز مقید است، دستگاه تونل هنوز حاضر است و گزارش بدون خطای تازه است در حالی که نقش کلاینت پایین است. اگر متوقف کردن کلاینت پاسخ‌های سرور به کاربران موجود را هم قطع کند، دو نقش چیزی را شریک‌اند که باید به یکی از آنها محدود می‌شد. ثبت کنید هر تغییر کدام نمونه، کدام فایل پیکربندی و کدام مالک جریان را لمس کرد، چون نفر بعدی که این میزبان را اشکال‌زدایی می‌کند وگرنه همان کشف را از صفر تکرار خواهد کرد.