از strongSwan به AWS Site-to-Site: چرا Child SA هیچ چیزی انتخاب نمی‌کند

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

نام‌های AWS را به اصطلاحات strongSwan ترجمه کنید

AWS اتصال را از سمت مشتری توصیف می‌کند: نشانی دروازه مشتری و CIDR محلی از آنِ شماست و CIDR راه دور متعلق به VPC است. strongSwan دو انتها را left و right می‌نامد، پیشوند شما در leftsubnet و پیشوند VPC در rightsubnet قرار دارد. جابه‌جا کردن یک جفت تونلی می‌سازد که ترافیک اشتباه را مذاکره و انتخاب می‌کند.

پیکربندی‌ای را که AWS برای این اتصال می‌سازد بارگیری کنید و آن را مرجع همان اتصال خاص بدانید، از جمله نشانی‌های تونل و پیشوندها. اگر هر دو فیلد CIDR را هنگام ساخت خالی بگذارید، سرویس در هر طرف از مقدار پیش‌فرض 0.0.0.0/0 استفاده می‌کند. آن‌گاه مسیریابی که با پیشوند باریک پیکربندی شده هرگز با آن مطابقت پیدا نمی‌کند، پس یا فیلدها را پر کنید یا انتخابگر را آگاهانه گسترده‌تر کنید.

ناسازگاری در اینجا شبیه خطای مسیریابی به نظر می‌رسد و چنین نیست.

نشانی‌ای را که AWS واقعاً می‌بیند تثبیت کنید

مسیریابی پشت NAT می‌تواند IKE را از رابطی ارسال کند که طرف مقابل هرگز از آن آگاه نشده است. نشانی دروازه ثبت‌شده در AWS باید همانی باشد که AWS روی شبکه می‌بیند و مسیریاب باید به همان نشانی محلی تثبیت شود، نه اینکه مسیر پیش‌فرض خود را دنبال کند.

conn %default
    local_addrs = 203.0.113.10

در strongSwan گزینه local_addrs نشانی مبدأ را برای IKE انتخاب می‌کند و پیکربندی‌های قدیمی‌تر OpenSwan همان ایده را left می‌نویسند. آن را به رابطی که نشانی عمومی دارد اشاره دهید، سپس روی خود دستگاه NAT بررسی کنید که UDP 500 و 4500 به آن میزبان می‌رسند، چون قاعده‌ای که از مسیریاب قبلی باقی مانده آن‌ها را بی‌صدا دور می‌ریزد. جفت انتخابگر درست با نشانی مبدأ اشتباه باز هم شکست می‌خورد و گزارش، پیشنهاد را سرزنش می‌کند. همین گمراه‌کردن دلیل آن است که نشانی مبدأ بررسی جداگانه‌ای می‌خواهد.

قاعده ارسال را تأیید کنید نه اینکه فرضش کنید، چون قاعده‌ای که برای مسیریاب قبلی درست بود غالباً باقی می‌ماند.

فاز 1 و فاز 2 را جداگانه بررسی کنید

AWS گزینه‌های IKE و ESP را به‌صورت فهرست‌های جداگانه نشان می‌دهد. مجموعه IKE که هر دو طرف می‌پذیرند درباره پیشنهاد ESP چیزی نمی‌گوید، چون این دو فهرست مستقل‌اند. هر دو را از پیکربندی تولیدشده بخوانید و یکی‌یکی مقایسه کنید.

conn aws
    ike = aes256-sha1-modp1024
    esp = aes256gcm16

نحو بین پیاده‌سازی‌ها منتقل نمی‌شود. جفتی که در OpenSwan کار می‌کند، مانند phase2alg=aes_gcm همراه با ike=aes256-sha1;modp1024، باید به قالب esp= و ike= در strongSwan ترجمه شود و نام الگوریتم‌ها متفاوت است. چون GCM هنگام رمزگذاری احراز اصالت می‌کند، به تبدیل یکپارچگی جداگانه نیاز ندارد، برخلاف مجموعه CBC همراه با SHA. خط فاز 2 که بدون ترجمه از یک دیمن به دیمن دیگر چسبانده شود، ردّی تولید می‌کند که مانند ناسازگاری انتخابگر خوانده می‌شود.

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

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

ipsec statusall

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

از میزبان داخل پیشوند محلی به میزبان داخل پیشوند VPC آزمایش کنید و مسیر بازگشت و هر گروه امنیتی یا ACL شبکه در سمت AWS را بررسی کنید. انتخابگرهای درست از دور ریخته‌شدن بعدی بسته محافظت نمی‌کنند.

وقتی پس از تطابق انتخابگرها باز هم شکست می‌خورد

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

پیش از تغییر پیشنهاد دیگری، یک بسته ورودی و یک بسته خروجی در هر طرف ثبت کنید.

ثبت کنید انتخابگرها، پیشنهادهای فاز 1 و فاز 2 و نشانی مبدأ را در تیکت. این چهار مقدار بیشتر شکست‌های site-to-site را بدون تماس توضیح می‌دهند.