هندشیک WireGuard کار می‌کند اما اینترنت نیست: بسته را دنبال کنید
هندشیک فقط کلیدها و دسترس‌پذیری را اثبات می‌کند. یک بسته را از AllowedIPs در طول ارسال، NAT و مسیر بازگشت دنبال کنید تا ببینید کجا متوقف می‌شود.
تونل بالاست، wg show یک هندشیک اخیر را گزارش می‌کند، می‌توانید آدرس تونل سرور را پینگ کنید و هیچ چیز بعد از آن پاسخ نمی‌دهد. غریزه این است که کلیدها را دوباره بسازید یا پیکربندی را دوباره به اشتراک بگذارید. این دقیقاً همان بخشی از مسیر را تغییر می‌دهد که قبلاً اثبات شده کار می‌کند.
یک هندشیک کامل‌شده می‌گوید که دو طرف درباره کلیدها توافق دارند، UDP به نقطه پایانی می‌رسد و مسیریابی رمزنگاری‌شده بسته را می‌پذیرد. درباره اینکه بسته بعد از آن می‌تواند سرور را ترک کند یا نه، چیزی نمی‌گوید.
پس به‌جای حدس زدن، یک بسته را دنبال کنید. چهار جا وجود دارد که بسته می‌تواند در آن بمیرد و هر کدام رد پای متفاوتی می‌گذارند.
هندشیک در واقع چه چیزی را اثبات می‌کند
WireGuard یک پروتکل UDP است که با هندشیک Noise یک نشست برقرار می‌کند و سپس بسته‌ها را برای همتا رمزنگاری می‌کند. وقتی wg show هندشیکی به قدمت چند ثانیه و شمارنده انتقال رو به افزایش را نشان می‌دهد، نقطه پایانی، کلیدها و کلید عمومی همتا همه درست هستند.
چیزی که اثبات نمی‌کند این است که کلاینت شما اصلاً ترافیک اینترنتی را وارد رابط کند، سرور مایل باشد آن را ارسال کند، یا پاسخ بتواند راه بازگشت را پیدا کند. اینها تصمیم‌های مسیریابی هسته و فایروال هستند و بیرون از تونل گرفته می‌شوند.
به همین دلیل پینگ آدرس تونل سرور آزمون چنان گمراه‌کننده‌ای است. آن بسته خطاب به خود سرور است، پس به‌صورت محلی پایان می‌یابد. هرگز به ارسال، هرگز به ترجمه و هرگز به مسیر بازگشت از اینترنت نیاز ندارد.
AllowedIPs یک تصمیم مسیریابی است
در کلاینت، AllowedIPs دو کار انجام می‌دهد. جدول مسیریابی کلید رمزنگاری است که تعیین می‌کند کدام آدرس‌های مقصد به تونل این همتا فرستاده می‌شوند، و فهرست آدرس‌های مبدأ است که همتا از شما می‌پذیرد. اگر پیکربندی کلاینت فقط 10.8.0.0/24 را فهرست کند، مقصدهای عمومی هرگز وارد رابط نمی‌شوند و مسیر پیش‌فرض معمول شما آنها را بیرون از تونل می‌برد. آن وقت تونل بی‌نقص کار می‌کند و هیچ‌یک از آنچه می‌خواستید را انجام نمی‌دهد.
به آنچه کلاینت واقعاً نصب کرده نگاه کنید، نه به آنچه فایل پیکربندی می‌گوید:
wg show wg0 allowed-ipsip route get 1.1.1.1
دستور دوم تعیین‌کننده است. اگر پاسخ رابط فیزیکی شما و دروازه معمول را نام می‌برد، بسته در تونل نمی‌رود و هیچ تغییری در سمت سرور آن را درست نمی‌کند. 0.0.0.0/0 را برای IPv4 و ::/0 را برای IPv6 جداگانه اضافه کنید؛ قاعده‌ای که همه چیز را برای یک خانواده می‌گیرد، دیگری را در مسیر اصلی‌اش رها می‌کند و این دلیل رایج تونل IPv4 سالم و جست‌وجوی IPv6 متوقف است.
بسته کجا روی دروازه می‌میرد
اگر مسیر درست است و بسته هنوز جایی نمی‌رود، به سرور می‌رسد و همان‌جا متوقف می‌شود. چهار بررسی بیشتر دروازه‌ها را پوشش می‌دهد.
ارسال. sysctl net.ipv4.ip_forward که 0 برمی‌گرداند پاسخ کلاسیک است و بسیاری از توزیع‌ها هنوز به‌طور پیش‌فرض 0 هستند. باید 1 باشد و باید به‌طور پایدار در فایل sysctl تنظیم شود، نه با دستوری که هنگام راه‌اندازی مجدد ناپدید می‌شود. ارسال IPv6 کلید جداگانه‌ای است.
سیاست فیلتر. زنجیره FORWARD با سیاست حذف پیش‌فرض، ترافیک تونل را دور می‌ریزد ولی ترافیک به خود میزبان را اجازه می‌دهد، که دقیقاً با نشانه‌ها می‌خواند. مجموعه قواعد زنده را بخوانید، نه فایل ذخیره‌شده: nft list ruleset یا iptables -S.
ترجمه یا مسیریابی. کلاینت‌هایی که از آدرس‌های تونل خصوصی استفاده می‌کنند یا به NAT مبدأ روی رابط خروجی سرور نیاز دارند یا به یک پیشوند مسیریابی‌شده که شبکه بالادست بداند چگونه بازگرداند. انتخاب میان این دو از طرح آدرس‌ها پیروی می‌کند. افزودن MASQUERADE به شبکه‌ای که پیشوند شما را از قبل بازمسیریابی می‌کند بی‌خطر ولی بی‌فایده است، و حذف آن جایی که هیچ مسیری وجود ندارد پاسخ‌ها را به محدوده خصوصی غیرقابل مسیریابی نشانه می‌رود.
مسیر بازگشت. در طراحی‌های مسیریابی‌شده، روتر بالادست به مسیری نیاز دارد که به سرور شما اشاره کند. شبکه ارائه‌دهنده هم می‌تواند آن را مسدود کند: چند ابر بررسی مبدأ و مقصد را روی نمونه فعال می‌کنند که بسته‌هایی را که مبدأشان آدرس خود نمونه نیست، بی‌صدا دور می‌ریزد تا آن بررسی غیرفعال شود.
DNS به شکلی متفاوت از مسیریابی شکست می‌خورد
بسته به یک آدرس شناخته‌شده و جست‌وجوی نام دو شکست جداگانه‌اند و پیام‌های خطا در دو جهت مخالف گمراه می‌کنند. اگر ping 1.1.1.1 کار کند و مرورگر چیزی بارگذاری نکند، مسیر درست است و تفکیک نام نه. اگر خود پینگ شکست بخورد، DNS بی‌ربط است و به بخش قبلی برگشته‌اید.
wg-quick می‌تواند یک resolver را از خط DNS = در پیکربندی تنظیم کند و systemd-resolved رفتار خود را برای هر پیوند دارد. VPNی که resolver را با آدرسی بازنویسی می‌کند که فقط داخل تونل قابل دسترسی است، هر جست‌وجو را در لحظه‌ای که تونل قطع شود شکست می‌دهد، که شبیه این است که تونل اینترنت را خراب می‌کند.
| Symptom | Layer to inspect |
|---|---|
| Tunnel address pings, nothing else does | Client route, then gateway forwarding |
| Public IP pings, hostnames fail | Resolver selection and reachability |
| Handshake completes, no reply ever | FORWARD policy or missing NAT on the server |
| Small requests work, large transfers stall | MTU and TCP MSS clamping |
ترتیبی که شواهد تولید می‌کند
ابتدا بررسی سمت کلاینت را اجرا کنید، چون یک دستور است و نیمی از احتمالات را حذف می‌کند. سپس تأیید کنید که سرور اصلاً برای خروج به اینترنت ساخته شده است؛ دروازه‌ای که برای دسترسی خصوصی ساخته شده، وقتی مقصدهای عمومی شکست می‌خورند خراب نیست.
روی سرور، هنگام فرستادن پینگ از کلاینت رابط را تماشا کنید: tcpdump -ni wg0 icmp باید درخواست را نشان دهد و tcpdump -ni eth0 icmp باید نشان دهد که خارج می‌شود، ترجمه‌شده یا نه. اگر روی اولی ظاهر شود و هرگز روی دومی نه، توقف محلی روی سرور است. اگر خارج شود و پاسخ برنگردد، مشکل بالادست است و این بحث دیگری است.
در پایان کاری کنید که اصلاح از راه‌اندازی مجدد جان سالم به در ببرد. ارسال جای آن در فایل sysctl است، قواعد فایروال جای آن در سرویسی که آنها را بارگذاری می‌کند، و مسیرهای کلاینت جای آن در پیکربندی‌ای که رابط را بالا می‌آورد، نه در شلی که فراموش خواهید کرد. دوباره وصل شوید، همان دو آزمون را تکرار کنید و تأیید کنید که شمارنده‌ها حرکت می‌کنند.