WireGuard DNS DNAT: مسیر پاسخ را فعال نگه دارید

DNAT مقصد را بازنویسی می‌کند، نه مبدأ را. پیش از افزودن قاعده تصمیم بگیرید که resolver بالادستی چگونه می‌تواند پاسخ دهد، و هر تطابق را محدود نگه دارید.

هدایت پرس‌وجوی DNS یک کلاینت WireGuard به resolver دیگر شبیه یک قاعده است و مانند سه تصمیم رفتار می‌کند. مقصد باید بازنویسی شود، بسته باید ارسال شود، و پاسخ باید راه بازگشت خود را از میان وضعیت ترجمه‌ای که gateway ساخته است پیدا کند. سوم را نادیده بگیرید و پرس‌وجو تمیز خارج می‌شود در حالی که کلاینت برای همیشه منتظر می‌ماند.

مثالی را در نظر بگیرید: کلاینت‌های مجاز در 10.77.0.0/24 که از wg0 می‌آیند، نشانی اعلام‌شده 10.77.0.1 را جویا می‌شوند و به resolverی در 203.0.113.53 نیاز دارند. نشانی بالادستی یک نگه‌دارندهٔ جای مستندسازی است و نه سرویس فعال.

تغییر مسیر یک پرس‌وجو فقط مقصد آن را عوض می‌کند

قاعدهٔ NAT مقصد در PREROUTING نشانی را پیش از تصمیم مسیریابی بازنویسی می‌کند، پس بسته سپس به سمت مقصد جدید و نه قدیمی مسیریابی می‌شود. نشانی مبدأ کلاینت با این عملیات دست‌نخورده می‌ماند. به همین دلیل قاعده‌ای که کامل به نظر می‌رسد می‌تواند هنوز سکوت تولید کند: درخواست اکنون به resolverی می‌رود که هرگز دربارهٔ بازهٔ خصوصی کلاینت چیزی نشنیده است. gateway یک فیلد را ترجمه کرد و مشکل دومی را به ارث برد.

هر دو حامل DNS به قواعد منطبق نیاز دارند، چون کلاینت وقتی پاسخ بریده می‌شود به TCP بازمی‌گردد.

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

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A PREROUTING -i wg0 -s 10.77.0.0/24 -d 10.77.0.1 -p udp --dport 53 -j DNAT --to-destination 203.0.113.53:53
iptables -t nat -A PREROUTING -i wg0 -s 10.77.0.0/24 -d 10.77.0.1 -p tcp --dport 53 -j DNAT --to-destination 203.0.113.53:53

مسیر پاسخ تصمیمی جداگانه است

دو چیدمان اجازه می‌دهند پاسخ برگردد، و انتخاب زودهنگام یکی یک جلسهٔ اشکال‌زدایی را ذخیره می‌کند. یا resolver بالادستی مسیری بازگشتی به 10.77.0.0/24 از طریق این gateway دارد، یا gateway مبدأ را در خروج ترجمه می‌کند تا پاسخ به نشانی‌ای برسد که بالادست از قبل می‌شناسد. هر دو کار می‌کنند؛ فقط یکی با کنترلی که روی بالادست دارید می‌خواند.

مسیریابی سزاوار اولین تلاش است، چون نشانی کلاینت را برای resolver قابل مشاهده نگه می‌دارد و از لایهٔ ترجمهٔ دوم پرهیز می‌کند. وقتی بالادست بیرون از کنترل شماست، ترجمهٔ مبدأ روی رابط خروج مشخص انتخاب عملی است.

آن ترجمه را به همان اندازهٔ تغییر مسیر محدود کنید، وگرنه قاعده تبدیل به NATی با کاربرد عمومی برای هر چیزی می‌شود که تصادفاً تطابق یابد:

iptables -t nat -A POSTROUTING -s 10.77.0.0/24 -d 203.0.113.53 -o eth0 -p udp --dport 53 -j MASQUERADE
iptables -t nat -A POSTROUTING -s 10.77.0.0/24 -d 203.0.113.53 -o eth0 -p tcp --dport 53 -j MASQUERADE

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

قواعد را باریک‌تر از آنچه وظیفه به نظر می‌رسد بنویسید

اجازهٔ ارسال به همان دامنه تعلق دارد. جریان کلاینت به resolver و ترافیک بازگشتی را که conntrack از قبل می‌شناسد مجاز کنید، به جای اینکه هر اتصال DNAT روی ماشین را بپذیرید. پذیرش فراگیر همچنین ارسال پورت‌هایی را مجاز می‌کند که هیچ ربطی به DNS ندارند.

resolver خود gateway مسیر کد دیگری است. پرس‌وجویی که محلی صادر می‌شود از OUTPUT می‌گذرد، بنابراین آزمایش از پوستهٔ gateway نه قاعدهٔ PREROUTING را تمرین می‌کند و نه سیاست ارسال را. به همین دلیل یک آزمون محلی می‌تواند قبول شود در حالی که هر کلاینت شکست می‌خورد، و عکس آن هم به همان اندازه رایج است.

هیچ‌چیز اینجا DNS روی HTTPS در پورت 443 یا DNS روی TLS در پورت 853 را پوشش نمی‌دهد، و هیچ‌چیز IPv6 را پوشش نمی‌دهد. کلاینتی با resolver IPv6 پیکربندی‌شده با خوشحالی کل چیدمان را نادیده می‌گیرد.

یک پرس‌وجوی تازه چه چیزی را اثبات می‌کند

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

dig @10.77.0.1 example.com A +short
conntrack -L -p udp --dport 53 | head

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

پیش از تغییر مسیر هر چیزی تأیید کنید که resolver نام‌هایی را که انتظار دارید می‌شناسد. جانشینی که به نام‌های عمومی پاسخ می‌دهد اما به ناحیهٔ خصوصی شما نه یک جست‌وجوی سالم را به NXDOMAINی تبدیل می‌کند که شبیه تونل خراب است. resolver را مستقیماً و از gateway آزمایش کنید، پیش از آنکه مسیر کلاینت درگیر شود. و مرجع افزونه‌های iptables معناشناسی DNAT و masquerade را که این قواعد به آن وابسته‌اند مستند می‌کند.

مقالات مرتبط