ipsec.conf یا swanctl.conf؟ یک فرانت‌اند strongSwan انتخاب کنید

یک پروفایل IKEv1 سالم از یک راهنمای قدیمی روی Ubuntu 24.04 فرود می‌آید و اولین تلاش شکست می‌خورد، چون دیمن هرگز فایل را نخوانده است. واکنش معمول این است که پروفایل را دوباره ویرایش کنیم. پرسش واقعی این است که کدام فرانت‌اند strongSwan نصب شده و سرویس در حال اجرا از کدام‌یک استفاده می‌کند. تا زمانی که به این پرسش پاسخ داده نشود، هر ویرایش به سمت بارگذاری نشانه می‌رود که ممکن است وجود نداشته باشد.

دو فایل، دو بارگذار، یک دیمن

چیدمان قدیمی starter فایل ipsec.conf را می‌خواند و اتصال‌ها را از طریق یکپارچگی مدیریت قدیمی خود به charon می‌سپارد. نقطهٔ ورود عملیاتی آن فرمان ipsec است.

چیدمان swanctl تعریف‌ها را از طریق VICI بارگذاری می‌کند، swanctl.conf را می‌خواند و با فرمان swanctl اداره می‌شود. دیمن charon که بومی systemd است با این رویکرد یکپارچه می‌شود.

هر دو می‌توانند روی یک ماشین نصب شوند و سردرگمی از همین‌جا شروع می‌شود. یک فایل زیر /etc تنها ثابت می‌کند که کسی آن را نوشته، نه اینکه فرایند در حال اجرا آن را بارگذاری کرده است. نصب همهٔ گزینه‌ها برای دیدن اینکه کدام کار می‌کند، میزبان‌ی با دو مسیر مدیریت و بدون مالک روشن می‌سازد. یک چیدمان را انتخاب کنید و دیگری را حذف یا غیرفعال کنید.

بسته‌ها و unitهای نصب‌شده را بخوانید

با حالت فقط‌خواندنی شروع کنید. نام بسته‌ها در Ubuntu 24.04 جدا هستند: strongswan-starter، strongswan-swanctl و charon-systemd. بستهٔ غایب اطلاعات مفیدی است، نه دستوری برای نصب آن.

بسته‌ها و unitها را در یک گذر فهرست کنید:

dpkg-query -W strongswan-starter strongswan-swanctl charon-systemd
systemctl list-unit-files '*strongswan*'

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

اگر واحد فعال strongswan-starter است، فایلی که اهمیت دارد ipsec.conf است. اگر charon-systemd همراه swanctl است، ipsec.conf فقط تزئین است.

از مسیر کنترل متناظر استفاده کنید

هر فرانت‌اند دیدگاه خودش را از اتصال‌ها و انجمن‌ها دارد. swanctl --list-conns تعریف‌های بارگذاری‌شده را نشان می‌دهد و swanctl --list-sas انجمن‌های فعال را. مسیر قدیمی از ipsec statusall استفاده می‌کند.

درهم‌آمیختن آن‌ها خطاهای گمراه‌کننده می‌سازد. نبودن سوکت VICI یا رد شدن درخواست کنترل، مشکلی در مسیر مدیریت است، نه شاهدی بر اینکه همتا احراز هویت را رد کرده است.

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

قالب، نسخهٔ IKE نیست

پروفایل قدیمی با keyexchange=ikev1 نسخهٔ IKEv1 را انتخاب می‌کند. اتصال swanctl از تنظیم نسخه استفاده می‌کند، جایی که 1 نسخهٔ IKEv1 را انتخاب می‌کند. این‌ها دو واژگان برای یک ایده‌اند، نه تبدیل.

نشانی‌های همتا، هویت‌های محلی و راه دور، منابع اعتبارنامه، پیشنهادها و انتخابگرهای child باید آگاهانه نگاشت شوند. چسباندن یک بلوک left/right در نحو swanctl هیچ‌یک از این کارها را انجام نمی‌دهد.

تغییر تنها نسخهٔ پروتکل، رایج‌ترین نیمه‌مهاجرت است. فایلی می‌سازد که بارگذاری می‌شود و سپس به دلایلی نامرتبط با نسخه در احراز هویت شکست می‌خورد. خود IKEv1 با RFC 9395 منسوخ شده، بنابراین همتای موجودی که هنوز آن را لازم دارد، به یک محدودیت سازگاری مستند و مسیر مهاجرت نیاز دارد، نه یک پیش‌فرض تازه.

پیش از دست زدن به پروفایل، بارگذار را بررسی کنید

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

دو مسیر کنترل مستقیماً به پرسش بارگذاری پاسخ می‌دهند:

swanctl --list-conns
ipsec statusall

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

مالکیت بسته، بارگذاری پیکربندی و سازگاری پروتکل را سه پرسش جدا در نظر بگیرید. فایلی که برای یک فرانت‌اند معتبر است، وگرنه بارها و بارها ویرایش می‌شود در حالی که دیمن دیگری در حال اجراست.