IPsec ESP: چه چیزی را حمل میکند و چگونه اثبات کنیم که جریان دارد
ESP در حالت تونل یک بسته IP داخلی را میپیچد و پیوندش را با SPI مشخص میکند. وضعیت را بخوانید، سپس ببینید چگونه یک جریان شمارندهها را حرکت میدهد.
ESP ترافیک را در یک VPN مبتنی بر IPsec حمل میکند و runbook آن با یک قاعده آغاز میشود: پیش از تغییر یک سیاست، پیوند امنیتی را بخوانید. بیشتر رفتارهای توضیحندادهٔ ESP به انتخابگری برمیگردد که مطابقت نداشت، حالتی که بهجای خواندن فرض شد، یا شمارندهای که کسی هنگام فرستادن یک جریان بررسی نکرد. سه گام زیر روشن میکند که چه چیزی چه چیزی را حمل میکند، اثبات میکند که یک جریان از آن استفاده میکند، و یک عقبنشینی باقی میگذارد که به حافظه وابسته نیست. هر گام یک مشاهده تولید میکند که ارزش نوشتن دارد.
پیش از خواندن، فیلدها را بشناسید
ESP یک سرآیند پیش از دادههای محافظتشده و یک دنباله پس از آن میگذارد. سرآیند شاخص پارامترهای امنیتی را حمل میکند که مشخص میکند گیرنده باید از کدام پیوند استفاده کند، شماره ترتیب برای تشخیص تکرار، و در دنباله بستهبندیای که بار مفید را برای رمزنگار همتراز نگه میدارد. فیلد سرآیند بعدی در دنباله میگوید محتوای محافظتشده چیست، و گیرنده از همین راه میفهمد چه چیزی را کپسولگشایی کرده است.
حالت تغییر میدهد که داخل آن حفاظت چه باشد. در حالت تونل، مادهٔ محافظتشده یک بسته IP داخلی کامل است و یک سرآیند بیرونی تازه آن را میان دو سر میبرد. در حالت انتقال، حفاظت بار مفید لایهٔ بالایی یک بستهٔ موجود را میپیچد، پس سرآیند IP دومی برای باز کردن وجود ندارد. اینکه کدام حالت به کار میرود واقعیتی از پیکربندی است، نه مسئلهای تفسیری. آن را از مدخل وضعیت بخوانید، نه اینکه از یک نمودار استنباط کنید.
هیچیک از دو حالت نشانیدهی بیرونی را که باید بسته را برساند پنهان نمیکند. این ویژگی طراحی است نه کاستی، و به همین دلیل ناظر میانی هنوز میتواند ببیند کدام دو نشانی با هم صحبت میکنند، حتی وقتی بار مفید مات است.
گام یک: وضعیت را بخوانید، سپس سیاست
مدخلهای وضعیت کلیدها و شمارندهها را نگه میدارند؛ مدخلهای سیاست انتخابگرهایی را نگه میدارند که تعیین میکنند چه چیزی مجاز به استفاده از آنهاست. در لینوکس هر دو بدون ضبط بسته دیده میشوند و خواندن آنها به این ترتیب دو پرسش را جدا نگه میدارد.
ip xfrm state
ip xfrm policy
در خروجی وضعیت، مبدأ و مقصد پیوند، حالت، و اینکه کپسولهسازی درگاههای UDP را نشان میدهد یا نه را بررسی کنید. این درگاهها یعنی گذر از NAT به کار میرود، که تغییر میدهد یک دیوار آتش میانی باید چه چیزی را اجازه دهد، اما نه اینکه کدام انتخابگرها یا کلیدها در دو سر اعمال میشوند.
سپس انتخابگرهای سیاست را بخوانید. انتخابگری که پیشوندی باریکتر از ترافیکی که آزمایش میکنید نام میبرد شایعترین دلیل این است که تونلی کارآمد به نظر میرسد جریانی را نادیده میگیرد، و انتخابگر برای پروتکل اشتباه همان سکوت را تولید میکند.
| Field | Where it appears | What it decides |
|---|---|---|
| Security parameter index | ESP header, and the receiving state entry | Which association and keys the receiver applies |
| Sequence number | ESP header | Replay detection for that association |
| Next header | ESP trailer | What the decapsulated payload contains |
| Inner IP header | Inside tunnel-mode payload only | The original source and destination the endpoints act on |
| Traffic selectors | Policy, not the packet | Which local traffic is allowed to use the association |
ابزارهای فروشندگان همان اطلاعات را به شکلی آسانتر چاپ میکنند. ipsec statusall در strongSwan پیوندهای فرزند، انتخابگرهایشان و شمارندههای بایتشان را فهرست میکند، که وقتی از قبل میدانید به کدام فرزند نگاه کنید، غالباً سریعتر از خواندن خروجی خام xfrm است.
گام دو: اثبات کنید یک جریان شمارندهها را حرکت میدهد
شمارندهها تنها وقتی معنا دارند که بدانید چه چیزی باید آنها را حرکت میداد، پس مبدأ و مقصدی برگزینید که انتخابگر قطعاً پوشش میدهد و یک درخواست بیضرر بفرستید. سپس همان مدخل را دوباره بخوانید و مقایسه کنید.
ip -s xfrm state
tcpdump -ni any esp
دو خوانش داستانهای متفاوتی میگویند. بستههایی که در سمت خروجی بالا میروند اما هرگز در سمت ورودی، به مشکل ارسال یا مسیر بازگشت اشاره دارند نه مشکل کلید، زیرا بسته کپسوله شد و رفت. اگر هیچ شمارندهای حرکت نکند، ترافیک هرگز با سیاست مطابقت نداشته است، و انتخابگر جایی است که باید نگاه کنید.
ضبط در همان گام کپسولهسازی روی سیم را تأیید میکند، از جمله اینکه بستههای بیرونی ESP هستند یا ESP کپسولهشده در UDP. همچنین نشانیهایی را نشان میدهد که واقعاً جریان را حمل کردند، و اینها گاهی با آنچه در پیکربندی میخواندید تفاوت دارند.
گام سه: یک چیز را تغییر دهید و عقبنشینی نگه دارید
پیش از ویرایش هر چیزی، مبدأ، مقصد، حالت، انتخابگرها و شمارندههای پیوند را ثبت کنید. اگر تغییری اوضاع را بدتر کند، همان ثبت به شما امکان میدهد وضعیت پیشین را بازگردانید، بهجای اینکه پیکربندی کارآمد را از یک حدس دوباره بسازید. آن ثبت یک دقیقه وقت میگیرد و بعداً یک ساعت صرفهجویی میکند. همچنین تنها اثر باقیماندهای است که از شخص تغییردهنده جان سالم به در میبرد.
یک انتخابگر یا یک پارامتر را تغییر دهید، دوباره بارگذاری کنید، و گام دو را روی همان جریان تکرار کنید. حذف یک پیوند هر جریانی را که از آن استفاده میکند فرو میریزد، پس ویرایش هدفمند و بارگذاری دوبارهٔ فرزند تقریباً همیشه بهتر از خالی کردن وضعیت برای دیدن اینکه چه میشود است.
عقبنشینی برای ویرایش انتخابگر، بازگرداندن سیاست پیشین و بارگذاری دوبارهٔ آن است، با این قید که طرف مقابل ممکن است در صورت مذاکرهشدن انتخابگر و نه محلی بودن آن، به تغییری متناظر نیاز داشته باشد. آن وابستگی را همان زمان که تازه است بنویسید، زیرا جفت نیمهبازگرداندهشده سختتر از هر یک از دو حالت نهایی قابل استدلال است.
سرانجام، دامنه را صادق نگه دارید. یک پیوند ESP در حال جریان اثبات میکند دو دروازه بخش را محافظت و تحویل میدهند، و هیچ نمیگوید آیا برنامهٔ بالادست کاربرانش را احراز هویت میکند یا آنچه ذخیره میکند را رمز میکند. اینها کنترلهای جدایی با شواهد جداگانهاند، و runbook تنها وقتی تمام است که نفر بعدی بتواند آن را از روی یادداشتها تکرار کند.