کلاینت OpenVPN به سرور می‌رسد اما به میزبان‌های LAN نمی‌رسد: چک‌لیست

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

گام یک: تصمیم مسیریابی کلاینت را تماشا کنید

پیش از دست زدن به سرور، ثابت کنید که کلاینت بسته را به تونل می‌فرستد. از کرنل بپرسید برای یک میزبان مشخص LAN از کدام رابط استفاده می‌کند، به‌جای خواندن کل جدول:

ip route get 192.168.50.10

اگر پاسخ آداپتور فیزیکی و دروازه دفتر شما را نام ببرد، هیچ تغییری در سمت سرور کمکی نمی‌کند. OpenVPN تنها زمانی مسیرها را توزیع می‌کند که سرور آن‌ها را هُل دهد، پس push "route 192.168.50.0 255.255.255.0" را در پیکربندی سرور جستجو کنید و پس از آن کلاینت را دوباره وصل کنید. بیشتر کلاینت‌ها مسیرهای هُل‌داده‌شده را هنگام اتصال اعمال می‌کنند، نه وقتی پروفایل را دوباره بارگذاری می‌کنید.

در Windows همین پرسش فرمان دیگری دارد. Find-NetRoute -RemoteIPAddress 192.168.50.10 رابط و پرش بعدی را که پشته انتخاب می‌کرد چاپ می‌کند و route print -4 نشان می‌دهد آیا پیشوند هُل‌داده‌شده اصلاً وجود دارد.

گام دو: تأیید کنید که سرور بسته را فوروارد می‌کند

اگر مسیر کلاینت درست باشد، بسته به سرور می‌رسد و سرور باید با فوروارد کردن آن موافقت کند. کلید کرنل نخستین دروازه است و sysctl net.ipv4.ip_forward باید 1 برگرداند. تنظیم آن با echo 1 > /proc/sys/net/ipv4/ip_forward تا راه‌اندازی مجدد بعدی کار می‌کند و دقیقاً به همین دلیل همان شکایت هفته‌ها بعد بازمی‌گردد.

آن را جایی بنویسید که از راه‌اندازی مجدد جان سالم به در ببرد:

echo 'net.ipv4.ip_forward = 1' > /etc/sysctl.d/99-openvpn-forward.conf
sysctl --system

دروازه دوم جدول فیلتر است. میزبانی که Docker روی آن نصب است اغلب سیاست FORWARD با مقدار DROP دارد و تونل آن تصمیم را به ارث می‌برد. iptables -L FORWARD -v -n هم سیاست و هم شمارنده‌های بسته را نشان می‌دهد؛ اگر سیاست DROP باشد، فوروارد کردن برای جهت تونل به LAN یک پذیرش صریح می‌خواهد و یکی برای پاسخ.

گام سه: بسته را تا LAN دنبال کنید و پاسخ را بجویید

هر دو سوی سرور را همزمان زیر نظر بگیرید. روی تونل و روی رابط LAN ضبط کنید، با فیلتر یک کلاینت و یک میزبان تا خروجی خوانا بماند:

tcpdump -ni tun0 host 192.168.50.10
tcpdump -ni eth0 host 192.168.50.10

درخواست‌هایی که روی tun0 و دوباره روی eth0 با مبدأ 10.8.0.x ظاهر می‌شوند و پس از آن سکوت است، یعنی بسته رسیده و پاسخ جای دیگری رفته است. میزبان LAN به دروازه پیش‌فرض خود پاسخ می‌دهد، آن دروازه هیچ مسیری برای استخر VPN ندارد و پاسخ روی روتر LAN می‌میرد. ping کردن میزبان LAN از سرور هیچ‌چیز درباره این مسیر ثابت نمی‌کند، چون آن ترافیک هرگز از تونل عبور نمی‌کند.

گام چهار: بین ترجمه و مسیر بازگشت یکی را انتخاب کنید

دو تعمیر سوراخ را می‌بندد و این انتخاب پیامدهایی فراتر از کار کردن ping دارد. ترجمه مبدأ سرور را فرستنده ظاهری می‌کند:

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE

قاعده را به استخر و رابط LAN محدود کنید، سپس آن را ماندگار کنید، وگرنه بارگذاری بعدی فایروال بی‌صدا تعمیر شما را حذف می‌کند. هزینه آن هویت است: هر کلاینت در گزارش‌های LAN و قواعد دسترسی مانند سرور VPN دیده می‌شود، و per-client policy becomes guesswork.

یک مسیر استاتیک برای 10.8.0.0/24 روی روتر LAN که به سرور VPN اشاره می‌کند، آدرس‌های کلاینت را دیدنی نگه می‌دارد و وقتی آن روتر مال شماست پاسخ بلندمدت بهتری است. بسیاری از سایت‌ها مدتی هر دو را اجرا می‌کنند، NAT برای تعمیر فوری و مسیر پس از نوشتن سیاست فایروال. اگر سرور به‌جای استخر یک همتای سایت‌به‌سایت باشد، سمت سرور هم به یک iroute برای زیرشبکه دور نیاز دارد، وگرنه مسیر همتا وجود دارد اما ترافیک کلاینت هرگز با آن مرتبط نمی‌شود.

گام پنج: از کلاینت تأیید کنید و ثبت کنید چه چیزی تغییر کرد

حلقه را از کلاینت ببندید، نه از سرور. به سرویسی واقعی روی میزبان LAN وصل شوید، سپس تأیید کنید که شمارنده‌های ترجمه با iptables -t nat -L POSTROUTING -v -n جابه‌جا شده‌اند، چون قاعده‌ای با صفر بسته قاعده‌ای است که هرگز مطابقت نداشته. conntrack -L -s 10.8.0.5 جریان و وضعیت آن را نشان می‌دهد وقتی به مدرکی نیاز دارید که جهت بازگشت ردیابی می‌شود.

در پیکربندی سرور یادداشتی بگذارید: کدام زیرشبکه، کدام رابط، کدام قاعده، و اینکه آیا روتر LAN مسیر بازگشت دارد یا نه. بار بعد که به‌روزرسانی کلاینت مسیری هُل‌داده‌شده را پاک می‌کند، آن یادداشت یک جلسه آتش‌نشانی را به تعمیری یک‌خطی تبدیل می‌کند.