StrongSwan آدرس DNS را می‌فرستد که Mac نمی‌تواند به آن برسد

همه‌چیز کار می‌کند تا کسی یک MacBook باز کند. تونل برقرار می‌شود، میزبان‌های داخلی با آدرس پاسخ می‌دهند و حل نام از کار می‌افتد. در iPhone همان پروفایل همین‌طور رفتار می‌کند، در حالی که کلاینت‌های Windows و Linux سالم‌اند. معمولاً ویژگی DNS ارسال‌شده مقصر است: سرور نشانی عمومی واسط خودش را توزیع می‌کند و کلاینت IKEv2 اپل پرس‌وجوها را از داخل تونل به آنجا نمی‌فرستد. resolver را به داخل استخر منتقل کنید و نشانه بدون دست زدن به کلاینت از بین می‌رود.

نشانه به نشانی ارسال‌شده اشاره می‌کند

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

نشانی عمومی انتخاب معمول است چون همانی است که مدیر قبلاً می‌شناسد. همچنین تنها نشانی است که تضمین‌شده بیرون از پیشوند خود تونل است، و همین ویژگی کلاینت‌های اپل را می‌شکند.

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

resolver را از بازه اجاره جدا کنید

به تونل نقشه آدرسی بدهید که resolver عضو زیرشبکه خود استخر باشد، سپس آن نشانی را رزرو کنید تا هرگز به هیچ کلاینتی اجاره داده نشود. در این مثال استخر 10.180.7.0/24 است، سرور 10.180.7.1 را نگه می‌دارد و اجاره‌ها از 10.180.7.2 شروع می‌شوند.

rightsourceip=10.180.7.2/24
rightdns=10.180.7.1

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

سرور برای این کار به واسط فیزیکی جدید نیاز ندارد. افزودن 10.180.7.1 به واسط loopback کافی است تا resolver بایند شود و پاسخ دهد، چون کلاینت‌ها از طریق مسیر استخری که از قبل وجود دارد به آن می‌رسند. نشانی را بیرون از بازه اجاره نگه دارید تا هیچ کلاینتی تصادفاً آن را نگیرد. اگر استخر توسط سرویس DHCP یا RADIUS خارجی مدیریت می‌شود، نشانی را آنجا هم رزرو کنید، وگرنه اولین کلاینتی که بپرسد آن را می‌گیرد.

resolver را بایند کنید و پورت 53 را ببندید

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

interface: 10.180.7.1
access-control: 10.180.7.0/24 allow
access-control: 0.0.0.0/0 refuse

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

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

iptables -A INPUT -p udp --dport 53 -s 10.180.7.0/24 -j ACCEPT
iptables -A INPUT -p tcp --dport 53 -s 10.180.7.0/24 -j ACCEPT
iptables -A INPUT -p udp --dport 53 -j DROP
iptables -A INPUT -p tcp --dport 53 -j DROP

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

بررسی کنید کلاینت واقعاً چه دریافت کرده است

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

swanctl --list-sas
swanctl --list-pools
dig +short @10.180.7.1 intranet.plant.example

پرس‌وجوی مستقیم ثابت می‌کند resolver روی نشانی استخر از میزبانی که می‌تواند به آن برسد پاسخ می‌دهد. ثابت نمی‌کند که Mac همان سرور را انتخاب کرده است. در macOS دستور scutil --dns resolverها را به‌ازای هر سرویس محدودشده فهرست می‌کند و از پنل خلاصه آموزنده‌تر است؛ در Windows دستور Get-DnsClientServerAddress نشان می‌دهد آداپتور تونل مقدار ارسال‌شده را پذیرفته یا نه.

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