دست‌دادن PiVPN کار می‌کند، صفحه‌ها متوقف می‌شوند: MASQUERADE را بررسی کنید

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

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

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

آدرس تونلی که به ping پاسخ می‌دهد در حالی که سایت‌های عمومی به پایان زمان می‌رسند، نشانه مشکل ارسال یا ترجمه است، نه دست‌دادن خراب. پنل وضعیت خود کلاینت نمی‌تواند این دو را از هم تشخیص دهد، چون فقط می‌داند که کانال کنترل بالاست. رابط تونل را روی سرور با این بررسی کنید: ip -br addr show tun0 و تأیید کنید که آدرس اختصاص‌یافته به کلاینت داخل استخری است که پیکربندی کرده‌اید. اگر استخر و آدرس کلاینت با هم نمی‌خوانند، اول آن را درست کنید، چون هر قاعده زیر با استخر مطابقت داده می‌شود.

سپس از سرور بپرسید برای رسیدن به یک آدرس عمومی از کدام رابط استفاده می‌کند. ip route get 203.0.113.9 دستگاه و منبع انتخاب‌شده را در خط اول خود چاپ می‌کند. نام آن دستگاه را بنویسید، چون همان مقداری است که قاعده NAT باید داشته باشد.

قاعده‌ای را بخوانید که تصمیم می‌گیرد بسته‌ها خارج می‌شوند یا نه

MASQUERADE فقط زمانی بسته را بازنویسی می‌کند که بسته از رابط نام‌برده در قاعده خارج شود. قاعده‌ای که به یک دستگاه سیمی محدود شده، برای ترافیکی که از Wi-Fi خارج می‌شود کاری نمی‌کند، و بسته آدرس مبدأ خصوصی خود را تا روتر بالادست حفظ می‌کند. آن روتر مسیری بازگشت به استخر تونل شما ندارد، پس پاسخ را دور می‌ریزد، و کلاینت اتصالی می‌بیند که باز می‌شود و سپس می‌میرد. نشانه با مقدار صفحه‌ای که پیش از نیاز به اولین پاسخ می‌رسد، بزرگ‌تر می‌شود.

جدول زنده را فهرست کنید و ستون رابط خروجی را بخوانید، نه اینکه فقط دنبال کلمه MASQUERADE بگردید. خروجی شکل افزودن آسان‌تر از یک فهرست قالب‌بندی‌شده قابل مقایسه است:

ip -br addr show tun0
ip route get 203.0.113.9
sudo iptables -t nat -S POSTROUTING

روی یک Raspberry Pi که زمانی از Ethernet و اکنون از Wi-Fi استفاده می‌کند، نام قدیمی تقریباً همیشه تمام ماجراست. نصب‌کننده ثبت کرده بود هنگام راه‌اندازی کدام دستگاه حاضر بود، و مجموعه قواعد ذخیره‌شده آن را در هر بوت دوباره اجرا می‌کند. پیش از تغییر هر چیز دیگری، دستگاه حاصل از جستجوی مسیر را با دستگاه موجود در قاعده مقایسه کنید. اگر یکی باشند، رابط مشکل شما نیست و باید به شمارنده‌های بخش آخر بروید. اگر متفاوت باشند، اصلاح، ویرایش یک کلمه در فایل ماندگاری است.

مجموعه قواعد ذخیره‌شده را اصلاح کنید، نه فقط نسخه در حال اجرا را

ویرایش فقط جدول زنده تا راه‌اندازی مجدد بعدی دوام می‌آورد، که دقیقاً به‌اندازه کافی طولانی است تا شما را قانع کند مشکل حل شده است. قواعدی که هنگام بوت برمی‌گردند در فایلی زندگی می‌کنند که یک بسته ماندگاری دیوار آتش آن را دوباره بار می‌کند. در تصاویر Pi مبتنی بر Debian آن فایل معمولاً /etc/iptables/rules.v4.

پیش از دست زدن به آن یک کپی بگیرید، سپس رابط خروجی در خط MASQUERADE را با دستگاهی که یادداشت کرده‌اید عوض کنید، برای مثال -o wlan0 به‌جای -o eth0. بازه مبدأ را همان‌طور که هست بگذارید، مگر اینکه استخر کلاینت‌های شما تغییر کرده باشد. دوباره بار کنید و تأیید کنید که قاعده اکنون دستگاه درست را نام می‌برد:

sudo cp /etc/iptables/rules.v4 /root/rules.v4.bak
sudo iptables-restore < /etc/iptables/rules.v4
sudo iptables -t nat -L POSTROUTING -v -n

فراموش کردن دو تنظیم مجاور آسان است. sysctl net.ipv4.ip_forward باید 1 گزارش دهد، و روتر بالادست نباید خودش آدرس‌های مبدأ خصوصی را فیلتر کند.

اثبات کنید قاعده فعال می‌شود، سپس جدا کنید چه چیزی هنوز کند است

شمارنده‌ها تنها اثبات صادقانه از مطابقت یک قاعده هستند. فهرست مفصل را اجرا کنید، دانلودی روی کلاینت شروع کنید و دوباره اجرا کنید. ستون‌های بسته و بایت کنار قاعده شما باید بالا روند، و قاعده‌ای که روی صفر می‌ماند هنوز مطابقت ندارد. اگر شمارنده‌ها حرکت می‌کنند اما صفحه‌ها هنوز شکست می‌خورند، بازه مبدأ را با استخر واقعی با این مقایسه کنید grep -n "^server " /etc/openvpn/server.conf. اگر حرکت می‌کنند و صفحه‌ها بار می‌شوند اما توان عبور ضعیف است، ترجمه تمام شده و مشکل باقی‌مانده جای دیگری است.

دو انتقال از همان کلاینت را مقایسه کنید، یکی به میزبان روی شبکه محلی و دیگری از طریق تونل به همان میزبان. کندی در هر دو حالت به پیوند خروجی Pi یا اتصال Wi-Fi اشاره دارد، نه به VPN. کندی فقط از طریق تونل به MTU و ارسال‌های دوباره اشاره دارد، که می‌توانید آن‌ها را با این بررسی کنید ip -s link show tun0 پیش از تغییر هر تنظیم رمزنگاری.

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