WireGuard VPN: فایل تنظیمات چه معنایی دارد، چگونه تونل را تأیید کنیم، و چه زمانی پروکسی ابزار بهتر است

جست‌وجو برای «WireGuard VPN» معمولاً دو چیز کاملاً متفاوت را برمی‌گرداند: پروتکل متن‌باز و اپ‌های کلاینت رسمی آن از یک سو، و فهرست بلندی از ارائه‌دهندگان تجاری که اجازه می‌دهند فایل تنظیمات آن را دانلود کنید از سوی دیگر. هر دو پاسخ درستی برای یک پرس‌وجو هستند، و همین باعث می‌شود بسیاری هنوز مطمئن نباشند چه چیزی نصب کرده‌اند.

این راهنما با WireGuard همان‌طور که هست رفتار می‌کند: پروتکلی با قالب تنظیمات کوچک و خوانا. وقتی چهار یا پنج خط آن فایل را بفهمید، بیشتر مشکلات WireGuard — «وصل می‌شود اما IP من تغییر نکرده»، «دست‌دادن (handshake) هرگز کامل نمی‌شود»، «فقط بعضی اپ‌ها تونل می‌شوند» — دیگر معما نیستند و به تنظیماتی تبدیل می‌شوند که می‌توانید اصلاح کنید.

WireGuard یک پروتکل است، نه یک اشتراک

WireGuard یک پروتکل VPN مدرن است که بر چارچوب پروتکل Noise ساخته شده است. از جفت‌کلیدهای Curve25519، و ChaCha20-Poly1305 برای رمزنگاری تأییدشده استفاده می‌کند و ترافیک خود را روی UDP حمل می‌کند. در Linux در کرنل اجرا می‌شود؛ در Windows، macOS، Android و iOS اپ‌های کلاینت رسمی رایگان و متن‌باز هستند.

این در عمل یعنی:

اگر فایل تنظیمات WireGuard دارید (معمولاً یک .conf یا یک کد QR)، می‌توانید آن را در کلاینت رسمی وارد کرده و وصل شوید — بدون نیاز به اپ فروشنده.
اگر سرور یا ارائه‌دهنده‌ای ندارید که برایتان یک peer بسازد، فایل تنظیمات به‌تنهایی هیچ کاری نمی‌کند. WireGuard شامل سرور، سیاست لاگ‌گیری یا kill switch نیست.
چون پروتکل کوچک و قالب استاندارد است، تنظیمات یک ارائه‌دهنده از نظر ساختاری با ارائه‌دهنده دیگر تفاوتی ندارد. آنچه متفاوت است endpoint، تعداد peer و سرویس پیرامون آن است.

خواندن فایل تنظیمات WireGuard خط به خط

یک تنظیمات کلاینت مینیمال دو بخش دارد. هر چیزی که برای اشکال‌زدایی نیاز داشته باشید اینجاست:

[Interface]
PrivateKey = <client-private-key>
Address = 10.7.0.2/32
DNS = 10.7.0.1

[Peer]
PublicKey = <server-public-key>
Endpoint = vpn.example.net:51820
AllowedIPs = 0.0.0.0/0, ::/0
PersistentKeepalive = 25

PrivateKey — سمت شما در جفت‌کلید. با آن مثل رمز عبور رفتار کنید؛ هر کسی که آن را داشته باشد می‌تواند جای peer شما را بگیرد.
Address — IP داخلی تونل که به شما اختصاص داده شده. این IP عمومی شما نیست و هرگز نباید با آن اشتباه گرفته شود.
DNS — resolverی که هنگام بالابودن تونل استفاده می‌شود. این خط را حذف کنید و ممکن است سیستمتان همچنان از DNS سروری که ISP از طریق DHCP داده استفاده کند، که شایع‌ترین نشت WireGuard است.
PublicKey / Endpoint — با چه کسی و کجا صحبت می‌کنید. endpoint یک میزبان و پورت UDP است.
AllowedIPs — خطی که بیشتر از همه اشتباه خوانده می‌شود. در کلاینت دو کار را همزمان انجام می‌دهد: جدول مسیریابی را برنامه‌ریزی می‌کند، و به‌عنوان فهرست کنترل دسترسی رمزنگاری‌شده برای اینکه peer کدام IPهای مقصد را از شما می‌پذیرد عمل می‌کند. 0.0.0.0/0, ::/0 یک تونل کامل است. مقدار محدودتر مثل 10.7.0.0/24 یک split tunnel است که فقط ترافیک را به آن subnet مسیریابی می‌کند.
PersistentKeepalive — هر N ثانیه یک بسته keepalive می‌فرستد تا NAT یا فایروال در دوره‌های بیکاری session را رها نکند. مقادیر استاندارد ۲۵ یا ۱۵ هستند؛ تنظیم خیلی پایین باتری موبایل را هدر می‌دهد.

اگر عمداً split tunnel می‌خواهید، AllowedIPs را محدود کنید نه اینکه بعد از آن ترافیک را فیلتر کنید — این تنظیم برای همین است. اگر می‌خواهید همه‌چیز تونل شود و نمی‌شود، اول AllowedIPs را بررسی کنید.

بالا آوردن تونل و اثبات کارکرد آن

در Linux و macOS با نصب wg-quick، تنظیمات در /etc/wireguard/wg0.conf قرار دارد:

sudo wg-quick up wg0
sudo wg show
ip route get 1.1.1.1
curl -s https://ifconfig.me/ip; echo

به چه چیزهایی توجه کنید:

wg show باید peer، یک endpoint و یک زمان latest handshake در چند دقیقه اخیر را فهرست کند. نبودن handshake یعنی تونل ترافیک را حمل نمی‌کند، حتی اگر interface وجود داشته باشد.
ip route get 1.1.1.1 باید interface WireGuard شما (مثل wg0) را نشان دهد، نه مسیر پیش‌فرض عادی.
curl باید IP عمومی مرتبط با endpointی که به آن وصل شده‌اید را برگرداند.
برای بررسی اینکه واقعاً کدام resolver پاسخ می‌دهد، یک نام آزمایشی DNS را از DNS سرور تنظیم‌شده‌تان بپرسید، نه اینکه فرض کنید خط DNS = اعمال شده است.

در Windows، macOS، Android و iOS، همان تنظیمات را در اپ رسمی وارد کنید. در Android و iOS می‌توانید تنظیمات را به‌صورت کد QR اسکن کنید. کلاینت رسمی Android از «Always-on VPN» هم پشتیبانی می‌کند — آن را فقط بعد از اینکه مطمئن شدید تونل به‌طور قابل‌اعتماد بالا می‌آید روشن کنید، چون handshake ناموفق به‌همراه always-on اتصال شما را قطع می‌کند و به‌جای برگشت بی‌صدا به شبکه باز، ارتباط را می‌بندد.

روتین تأیید سه‌دقیقه‌ای

قبل از اتصال IP عمومی خود را یادداشت کنید.
وصل شوید، سپس زمان handshake را با wg show بررسی کنید.
دوباره IP عمومی خود را بررسی کنید و تأیید کنید تغییر کرده است.
یک پرس‌وجوی DNS اجرا کنید و تأیید کنید resolver پاسخ‌دهنده با تنظیمات تونل شما همخوانی دارد، نه با ISP شما.
قطع کنید و تأیید کنید IP برمی‌گردد — اگر برنگشت، یک مسیر استاتیک یا تنظیم always-on جا گذاشته‌اید.

WireGuard در برابر OpenVPN در برابر پروکسی SOCKS5

این سه ابزار مدام با هم مقایسه می‌شوند و مشکلات متفاوتی را حل می‌کنند. یک نقشه تقریبی:

	WireGuard	OpenVPN	پروکسی SOCKS5
دامنه	کل دستگاه (یا split tunnel بر اساس subnet)	کل دستگاه	هر اپ یا هر درخواست
پروتکل	UDP (بعضی کلاینت‌ها TCP fallback اضافه می‌کنند)	TCP یا UDP	TCP (با UDP association)
رمزنگاری	بله، در لایه شبکه	بله، در لایه شبکه	خیر — تونل فقط به‌اندازه چیزی که روی آن اجرا می‌شود محافظت‌شده است
چرخش IP خروجی	خیر، یک peer به‌ازای هر interface	خیر، به‌صورت پیش‌فرض	بله، اگر ارائه‌دهنده چرخش دهد
کاربردهای معمول	مرور خصوصی، دسترسی از راه دور، لینک‌های site-to-site	همان، با سازگاری قدیمی‌تر گسترده‌تر	اسکرپینگ، بررسی جغرافیایی، مسیریابی هر اپ، اتوماسیون

نسخه کوتاه: وقتی می‌خواهید همه‌چیز روی دستگاه از یک endpoint رمزنگاری‌شده خارج شود از WireGuard استفاده کنید. وقتی می‌خواهید یک فرایند از یک IP خارج شود — یک مرورگر، یک اسکرپر، یک ابزار CLI — و می‌خواهید آن IP را بدون دست‌زدن به بقیه سیستم تغییر دهید، از پروکسی SOCKS5 استفاده کنید.

جایی که WireGuard ابزار ضعیف است

WireGuard دو محدودیت واقعی دارد که ارزش دانستن دارند پیش از آنکه جریان کاری‌ای بر پایه آن بسازید:

شناسایی آن آسان است و در بعضی شبکه‌ها مسدود یا محدود می‌شود. handshake آن متمایز است و روی UDP سوار می‌شود. در محیط‌هایی که UDP فیلتر می‌شود — شبکه‌های شرکتی، بعضی دانشگاه‌ها، بعضی شبکه‌های ملی — یک تونل ساده WireGuard اصلاً بالا نمی‌آید. هیچ لایه مبهم‌سازی توکاری ندارد؛ هر استتاری باید از سمت کلاینت یا سرویسی که آن را می‌پیچد بیاید.
چرخش ندارد. یک peer WireGuard به یک endpoint نگاشت می‌شود و IP عمومی شما همان چیزی است که آن endpoint ارائه می‌دهد. اگر کار شما به IP جدید برای هر درخواست یا هر منطقه نیاز دارد، استخر پروکسی چرخشی ابزار درست است و WireGuard ابزار نادرست.

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

چه زمانی پروکسی SOCKS5 انتخاب بهتری است

وقتی به‌جای VPN سراغ پروکسی بروید:

فقط یک اپلیکیشن باید جابه‌جا شود. یک مرورگر یا اسکریپت را مسیریابی کنید بدون دست‌زدن به بقیه ترافیک سیستم. در Linux این معمولاً proxychains یا یک wrapper هر اپ است؛ در Windows، ابزاری که قوانین را بر اساس هر فایل اجرایی اعمال می‌کند.
کار به IPهای زیادی نیاز دارد. وب‌اسکرپینگ، پایش قیمت و رهگیری رتبه به یک استخر و سیاست چرخش نیاز دارند، نه یک endpoint پایدار. تفاوت چرخش هر درخواست با sessionهای sticky را در نظر بگیرید — در هر چیزی که موقعیت یا قیمت گزارش می‌کند، ثبات مکان مهم‌تر از حجم خالص است.
سایتی را به‌عنوان یک منطقه خاص تست می‌کنید. خروجی پروکسی در کشور هدف روش سبک‌تر و سریع‌تری برای دیدن آن نسخه منطقه‌ای است تا بالا آوردن یک تونل کامل.
کنترل دستگاه را ندارید. واردکردن تنظیمات در بیشتر پلتفرم‌ها به حقوق administrator نیاز دارد؛ اشاره یک اپ به socks5h://host:port معمولاً نیاز ندارد.

این دو متقابلاً انحصاری نیستند. مسیریابی یک اتصال پروکسی در داخل تونل WireGuard الگویی عادی است: شما انتقال رمزنگاری‌شده به سروری که به آن اعتماد دارید را می‌گیرید، و پروکسی IP خروجی و چرخش را روی آن فراهم می‌کند. فقط روشن باشید کدام لایه چه کاری انجام می‌دهد، چون DNS resolution جایی است که این دو بیشتر از همه با هم اختلاف پیدا می‌کنند.

پنج دلیل برای «VPN روشن است اما هیچ‌چیز تغییر نکرده»

kill switch وجود ندارد. تونل قطع شده و همه‌چیز بی‌صدا به مسیر عادی شما برگشته است.
AllowedIPs خیلی محدود است. split tunnel تنظیم کرده‌اید و فراموش کرده‌اید، بنابراین فقط یک subnet مسیریابی می‌شود.
DNS همچنان محلی است. خط DNS = وجود ندارد، یا اپی از DNS-over-HTTPS به resolverی خارج از تونل استفاده می‌کند.
یک پروکسی یا VPN دوم از قبل فعال است. تنظیمات پروکسی سطح مرورگر برای آن مرورگر بر تونل سیستمی غلبه می‌کند، که رفتار عمدی است اما وقتی تصادفی رخ دهد گیج‌کننده است.
IPv6. اگر تنظیمات شما فقط 0.0.0.0/0 را پوشش می‌دهد و نه ::/0، مقصدهای دارای قابلیت IPv6 ممکن است مسیر تونل‌نشده را بروند.

چک‌لیست کوتاه تصمیم‌گیری

قبل از نصب هر چیزی، به این سه سؤال پاسخ دهید:

آیا کل دستگاه باید جابه‌جا شود یا یک اپ؟ کل دستگاه به WireGuard یا OpenVPN اشاره دارد؛ یک اپ به پروکسی.
آیا IP خروجی باید پایدار بماند یا مرتب تغییر کند؟ پایدار به تونل اشاره دارد؛ متغیر به استخر پروکسی چرخشی.
آیا شبکه‌ای که روی آن هستید UDP را مجاز می‌داند؟ اگر نه، از همان ابتدا برای fallback مبتنی بر TCP یا یک پروکسی برنامه‌ریزی کنید.

نتیجه‌گیری

WireGuard پروتکلی با تنظیمات پنج‌خطی و سطح حمله بسیار کوچک است، و همین دلیل سریع، قابل‌حمل و آسان برای تأیید بودن آن است. AllowedIPs و DNS را با دقت بخوانید، handshake را با wg show تأیید کنید، و بعد از آن IP عمومی و resolver خود را بررسی کنید — این چهار مرحله بیشتر شکایت‌ها را حل می‌کنند. وقتی مشکل شما «یک اپ به‌طور مکرر به IP متفاوت نیاز دارد» است، دیگر سعی نکنید آن را با تونل حل کنید و به‌جایش از پروکسی SOCKS5 استفاده کنید. این ابزارها مکمل هم هستند، و دانستن اینکه کدام لایه را تغییر می‌دهید تفاوت بین یک راه‌اندازی کارآمد و یک بعدازظهر اشکال‌زدایی مسیرهاست.