احراز هویت EAP روی IKEv2 می‌تواند از کلاینت بخواهد دو نام سرور متفاوت را در یک اتصال اعتبارسنجی کند. دروازه‌ای که IKE را پایان می‌دهد یک هویت ارائه می‌کند، و بخش پشتی EAP که تبادل درونی TLS را پایان می‌دهد ممکن است هویت دیگری ارائه کند. در strongSwan این دو در بلوک‌های پیکربندی متفاوت زندگی می‌کنند، و گذاشتن نام در بلوک اشتباه خرابی‌ای تولید می‌کند که شبیه مشکل گواهی به نظر می‌رسد. خواندن اینکه کدام اعتبارسنجی شکست خورده است همان چیزی است که می‌گوید کدام بلوک را ویرایش کنید.

یک اتصال، دو هویت سرور

هویت نخست به تبادل IKE تعلق دارد. کلاینت نشانی‌ای را شماره می‌گیرد و انتظار دارد طرف مقابل هویت مشخصی را اثبات کند، معمولاً نام موجود در گواهی دروازه.

هویت دوم به EAP تعلق دارد. با PEAP یا TTLS، کلاینت تونل TLS به سرور احراز هویت درون IKE SA می‌سازد، و آن سرور درونی گواهی خودش را ارائه می‌کند. وقتی بخش پشتی میزبان جداست، نامش با نام دروازه تفاوت دارد. کلاینتی که فقط نام اول را بررسی می‌کند هر آنچه نام دوم ادعا کند می‌پذیرد. و کلاینتی که با یک نام در هر دو جا پیکربندی شده باشد، به محض اینکه آن دو واقعاً متفاوت شوند شکست می‌خورد.

هر دو نام از پیکربندی اپراتور می‌آیند، نه از گواهی‌ای که خطا را برمی‌دارد. پرسیدن جزئیات استقرار از اپراتور سریع‌تر از حدس زدن دو نام میزبان است.

کدام فیلد به کدام لایه تعلق دارد

در swanctl نشانی و هویت IKE تنظیمات جداگانه‌اند، و هویت EAP سومی است.

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

connections {
    office {
        remote_addrs = vpn.example.com
        local {
            auth = eap-peap
            aaa_id = auth.example.com
        }
        remote {
            auth = pubkey
            id = vpn.example.com
        }
    }
}

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

چرا aaa_id زیر local زندگی می‌کند

بلوک local توصیف می‌کند این طرف در هنگام احراز هویت چه می‌کند، از جمله روشی که استفاده خواهد کرد و هویتی که انتظار دارد طرف دیگر برای آن روش ارائه دهد. هیچ چیز در آن ادعا نمی‌کند سرور AAA روی همان ماشین اجرا می‌شود.

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

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

رابط‌هایی که نمی‌توانند این تفکیک را بیان کنند

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

این زمانی مهم است که استقرار واقعاً به دو نام نیاز دارد. فیلدی با برچسب هویت سرور ممکن است یک لایه را پیکربندی کند و لایه دیگر را نه، بنابراین پروفایل می‌تواند درست به نظر برسد و باز هم در بررسی درونی شکست بخورد. پیش از فرض اینکه پروفایل می‌تواند این ترتیب را بیان کند، بررسی کنید افزونه نصب‌شده از چه چیزی پشتیبانی می‌کند. اگر نمی‌تواند، انتخاب با اپراتور است: مسیر تأمین متفاوت، یا طراحی اصلاح‌شده هویت سرور. ضعیف کردن PEAP یا پذیرش هر نامی سیاست احراز هویت را تغییر می‌دهد نه اینکه آن را درست کند.

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

ناهمخوانی هویت را از گواهی منقضی تشخیص دهید

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

swanctl --list-conns
swanctl --list-sas
journalctl -u strongswan -n 50 --no-pager

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

مقالات مرتبط