به OpenVPN وصل شده‌اید اما هیچ‌چیز بارگذاری نمی‌شود: یک مسیر گام‌به‌گام از سمت کلاینت

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

از کلاینت شروع کنید و به سمت بیرون بروید

سه آزمون را به این ترتیب اجرا کنید و بنویسید اولین کدام شکست می‌خورد. به نشانی تونل سرور ping کنید، که ثابت می‌کند خود تونل ترافیک را حمل می‌کند. به یک نشانی عمومی با شماره ping کنید، که هدایت و ترجمه را بدون دخالت دادن حل نام ثابت می‌کند. سپس تلاش کنید یک نام میزبان را حل کنید، که تنها آزمونی است که DNS را به کار می‌گیرد. هر نتیجه یک لایهٔ کامل را از ظن خارج می‌کند.

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

دو ضبط نشان می‌دهند بسته‌ها کجا متوقف می‌شوند

در حالی که از کلاینت ping به یک نشانی عمومی در جریان است، یک ضبط روی رابط تونل و یک ضبط روی پیوند بالادستی که قرار است به اینترنت برسد بگیرید. هر دو را هم‌زمان اجرا کنید تا مهرهای زمانی هم‌تراز شوند.

sudo tcpdump -ni tun0 -c 20 icmp
sudo tcpdump -ni enp1s0 -c 20 icmp

اگر درخواست‌ها روی تونل ظاهر شوند و هرگز روی پیوند بالادستی نه، سرور آن‌ها را میان تونل و سیم انداخته است و علت هدایت یا سیاست فایروال برای هدایت است، نه NAT. اگر روی هر دو ظاهر شوند، سرور سهم خود را انجام داده و پاسخ در بیرون گم شده است، که به ترجمه، یک فیلتر بالادست یا محدودیت ارائه‌دهنده اشاره دارد.

نام پیوند بالادستی را از جدول مسیریابی بگیرید، نه از یک آموزش. تصاویر ابری و آداپتورهای تغییرنام‌داده به‌ندرت با رابط نمونه در یک راهنما مطابقت دارند، و ضبط گرفتن روی دستگاه اشتباه دقیقاً شبیه سروری است که هدایت نمی‌کند:

ip -4 route get 9.9.9.9

فیلد dev در آن خروجی همان نامی است که قاعدهٔ NAT بعداً لازم دارد، پس آن را نگه دارید.

هدایت یک کلید در هسته و یک سیاست فایروال است

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

sysctl net.ipv4.ip_forward
printf 'net.ipv4.ip_forward=1\n' > /etc/sysctl.d/70-vpn-forward.conf
sysctl --system

هدایت فقط نیمی از کار است. روی میزبانی با UFW سیاست هدایت در /etc/default/ufw تنظیم می‌شود و باید ACCEPT باشد تا بارگذاری مجدد اثر کند. رد پیش‌فرض در مسیر هدایت، دست‌دادن را کاملاً سالم می‌گذارد اما هر بسته‌ای را که بخواهد از تونل خارج شود بی‌صدا دور می‌ریزد، و این دقیقاً همان نشانه‌ای است که با آن شروع کردید.

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

رابط خروج واقعی را در قاعدهٔ NAT نام ببرید

ترجمهٔ مبدأ به رابطی تعلق دارد که واقعاً میزبان را ترک می‌کند، با استخری که سرور توزیع می‌کند. هر دو نیمهٔ آن قاعده باید واقعیت را توصیف کنند و هیچ‌کدام اختیاری نیست.

iptables -t nat -A POSTROUTING -s 10.44.0.0/24 -o enp1s0 -j MASQUERADE

شکست کلاسیک قاعده‌ای است که از یک راهنما کپی شده و -o eth0 می‌گوید روی ماشینی که آداپتور آن نام دیگری دارد. قاعده بدون هشدار نصب می‌شود، با هیچ‌چیز مطابقت ندارد و کلاینت هنوز اینترنت ندارد. استخر نیمهٔ دیگر همان اشتباه است: اگر سرور 10.44.0.0/24 را توزیع کند و قاعده 10.8.0.0/24 را پوشش دهد، هیچ‌چیز هرگز مطابقت نخواهد کرد.

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

iptables -t nat -L POSTROUTING -v -n

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

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

DNS شکست دوم پشت شکست اول است

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

یک حل‌کننده از سرور بفرستید تا کلاینت بداند کجا بپرسد. دو ورودی به کلاینت یک جایگزین می‌دهند اگر اولی در دسترس نباشد، و هر دو باید حل‌کننده‌هایی باشند که تونل واقعاً اجازه می‌دهد.

push "dhcp-option DNS 9.9.9.9"
push "dhcp-option DNS 149.112.112.112"

کلاینت‌های Windows ممکن است با این حال به حل‌کنندهٔ محلی برگردند، و block-outside-dns دقیقاً برای جلوگیری از همین وجود دارد، به بهای از دست دادن نام‌هایی که فقط شبکهٔ محلی می‌تواند حل کند. کلاینت‌های Linux با systemd-resolved اغلب حل‌کنندهٔ فرستاده‌شده را نادیده می‌گیرند مگر اینکه اسکریپتی آن را نصب کند، پس پیش از نتیجه‌گیری که ارسال نادیده گرفته شد، resolvectl status را برای دستگاه تونل بررسی کنید.

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