تونل کامل در strongSwan به 0.0.0.0/0 روی هر دو طرف نیاز دارد

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

ابتدا انتخابگر کارخواه را بررسی کنید

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

children {
    net {
        local_ts  = dynamic
        remote_ts = 0.0.0.0/0
    }
}

این قطعه یک فایل اتصال کامل نیست، و این یکی فرض می‌کند احراز هویت، هویت‌ها و مجموعه آدرس‌های مجازی از قبل پیکربندی شده‌اند. انتخابگر مبدأ کارخواه و آدرسی که سرور تخصیص می‌دهد هنوز باید هم‌خوانی داشته باشند، وگرنه child SA با گستره‌ای بالا می‌آید که هیچ‌یک از دو طرف انتظارش را نداشت. آن را با swanctl --load-all بارگذاری کنید و پیش از فرض موفقیت خروجی را بخوانید. فایلی که تجزیه می‌شود هنوز می‌تواند به‌خاطر انتخابگری که با پیشنهاد طرف مقابل هم‌پوشانی ندارد رد شود.

انتخابگر دروازه را در طرف خودش بررسی کنید

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

children {
    rw {
        local_ts  = 0.0.0.0/0
        remote_ts = 10.77.0.0/24
    }
}

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

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

child SA توافق‌شده را بررسی کنید، نه فایل را

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

swanctl --list-conns
swanctl --list-sas
ip xfrm policy list

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

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

ارسال و مسیر بازگشت را بررسی کنید

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

sysctl net.ipv4.ip_forward
iptables -t nat -S | grep -i masq
ip route get 1.1.1.1

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

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

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

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

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

resolvectl query intranet.example.internal
traceroute -n 1.1.1.1

زنجیره را با آن دو دستور به‌همراه انتخابگرهای توافق‌شده از فهرست بالا تأیید کنید. اگر traceroute روتر محلی را به‌عنوان نخستین گام نشان دهد، ترافیک از تونل استفاده نمی‌کند هر چه انتخابگرها ادعا کنند. دسترسی به اینترنت تنها زمانی کامل است که ترافیک برگزیده از دروازه طراحی‌شده پذیرفته، ارسال و بازگردانده شود. یافتن 0.0.0.0/0 در یک نمایه آغاز آن زنجیره است نه اثباتش.