سرور یا کارخواه: کدام واحد OpenVPN روی Pi با نقش دوگانه

دو فرایند OpenVPN روی یک Pi اجرا می‌شوند که هم کاربران کوچ‌گرد را می‌پذیرد و هم به ارائه‌دهندهٔ بالادست می‌رسد، و آن‌ها جز سخت‌افزار تقریباً چیزی را شریک نمی‌شوند. یکی به تونل‌های ورودی گوش می‌دهد و دیگری به بیرون شماره می‌گیرد. هر کدام پوشهٔ خودش را می‌خواند و هر کدام حالت خرابی خودش را دارد. راه‌اندازی مجدد واحد اشتباه رایج‌ترین راهی است که یک اصلاح کارخواه به جای آن شنونده را از جا در می‌برد.

نام واحد را با پوشه‌ای که بار می‌کند هم‌خوان کنید

بالادست 2.6 دو واحد الگو ارائه می‌دهد: [email protected] و [email protected]. الگوی سرور در /etc/openvpn/server آغاز می‌شود و از آنجا %i.conf را بارگذاری می‌کند. الگوی کارخواه در /etc/openvpn/client آغاز می‌شود. نمونه‌ای با نام roaming می‌تواند هم‌زمان در هر دو جا وجود داشته باشد، هم به‌عنوان سرور و هم به‌عنوان کارخواه، با دو پیکربندی بی‌ارتباط و هیچ پیوندی میان آن‌ها جز رشته.

از systemd بپرسید نه از سامانهٔ پرونده‌ها، چون بسته‌سازها فایل‌های افزوده‌ای می‌افزایند که می‌تواند پوشهٔ کاری یا آرگومان‌هایی را که فایل دودویی می‌گیرد تغییر دهد.

systemctl list-units --type=service 'openvpn-*@*'
systemctl cat [email protected]
systemctl show -p WorkingDirectory -p ExecStart [email protected]

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

بر اساس جهت بسته تصمیم بگیرید، نه بر اساس نام رابط

نمونهٔ سرور یک سوکت شنود دارد و اتصال‌ها را می‌پذیرد. ترابری رمزگذاری‌شدهٔ آن ورودی محلی و خروجی محلی روی Pi است، در حالی که ترافیکی که برای کاربران پیش می‌فرستد مسیر پیش‌فرست را دنبال می‌کند و به مجموعهٔ دیگری از قواعد پاسخ می‌دهد. نمونهٔ کارخواه در آن معنا شنونده‌ای ندارد: به یک همتا شماره می‌گیرد، پس ترابری رمزگذاری‌شده‌اش خروجی محلی به سوی لایهٔ زیرین است.

این تفاوت به شما می‌گوید یک قاعده به کجا تعلق دارد. قاعده‌ای که با یک رابط درون زنجیرهٔ پیش‌فرست مطابقت دارد تنها ترافیکی را مجاز می‌کند که مسیریابی پیش‌تر انتخاب کرده است؛ هرگز مسیر را انتخاب نمی‌کند. وقتی بسته‌های کاربر کوچ‌گرد از راه اشتباه بیرون می‌روند، زنجیره‌ای که باید بررسی شود forward است، نه output.

پیش از نظریه‌پردازی به سوکت‌ها نگاه کنید. سروری که به udp/1194 بسته شده یک سوکت شنود نشان می‌دهد. کارخواه پیوندی با نشانی ارائه‌دهنده نشان می‌دهد و هیچ چیز شنونده‌ای.

ss -lunp | grep openvpn
ss -unp state established '( dport = :1194 or sport = :1194 )'

مسیر پیش‌فرض یک نمونه می‌تواند پاسخ‌های دیگری را برباید

یک redirect-gateway که کارخواه بالادست هل می‌دهد، مسیر پیش‌فرضی نصب می‌کند که با همهٔ چیزهای دیگر روی دستگاه رقابت می‌کند، از جمله پاسخ‌هایی که سرور برای کاربران کوچ‌گرد می‌فرستد. OpenVPN برای نشانی همتای خودش استثنایی می‌گذارد تا تونل در دسترس بماند، اما آن استثنا هیچ چیزی دربارهٔ تلفنی در شبکهٔ یک هتل نمی‌گوید.

نشانه معمولاً نامتقارن است. دست‌دادن کامل می‌شود، کارخواه اتصال را گزارش می‌کند، و ترافیک پس از نخستین بستهٔ پاسخ می‌میرد. مسیریابی سیاستی مبتنی بر مبدأ، یا نشانهٔ بسته‌ای که با --mark روی نمونهٔ سرور گذاشته می‌شود، دو جریان را جدا نگه می‌دارد؛ هیچ‌یک به‌تنهایی مجموعهٔ کاملی از قواعد نیست و هر دو به مسیرهای معتبر در جدولی که برمی‌گزینند نیاز دارند.

تصمیم محلی را بیازمایید نه وضعیت تونل را، چون هسته پیش از آن‌که OpenVPN بسته را ببیند مبدأ و رابط را برمی‌گزیند.

ip route get 203.0.113.44
ip rule show

یک نقش را دوباره راه‌اندازی کنید و ثابت کنید نقش دیگر زنده ماند

ترتیب اهمیت دارد وقتی هر دو نقش به یک لایهٔ زیرین وابسته‌اند. اگر مسیر بالادست باید پیش از پیش‌فرست ترافیک کاربران وجود داشته باشد، نخست کارخواه را دوباره راه‌اندازی کنید، و اگر تنها شنونده یا استخر آن را تغییر می‌دهید، نخست سرور را. در هر حال پس از آن هر دو واحد را تأیید کنید، چون راه‌اندازی مجدد ناموفق می‌تواند نقش دیگر را با وضعیت کهنه در حال اجرا بگذارد.

شرط توقف را پیش از تغییر بنویسید: آیا از دست دادن تونل بالادست کاربران کوچ‌گرد را مسدود می‌کند، یا به پیوند بالاروی خود Pi برمی‌گردد؟ DNS و IPv6 نیز پاسخ روشن می‌خواهند، چون یک تبدیل‌گر هل‌داده‌شده اغلب بیش از مسیری که آن را سودمند کرد زنده می‌ماند.

systemctl restart [email protected]
systemctl is-active [email protected]
journalctl -u [email protected] -n 20 --no-pager

تغییر را تنها وقتی بپذیرید که سه چیز هم‌زمان برقرار باشد: اتصال ورودی تازه کامل می‌شود، برنامهٔ پیش‌فرست‌شده از خروجی موردنظر به مقصدش می‌رسد، و هر دو فرایند هنوز همتای مورد انتظار خود را گزارش می‌کنند. اگر یکی از سه شکست بخورد، نمونهٔ اشتباه یا مسیر اشتباه را تغییر داده‌اید و گام بعدی خواندن دوبارهٔ واحد است، نه راه‌اندازی مجدد چیز دیگری.