ESP خروجی بدون پاسخ به معنای مرده بودن VPN نیست
ESP برای هر تداعی یک جهت را محافظت میکند و چیزی را تأیید نمیکند. پیش از ناتوان خواندن سرور، گفتوگوی درونی و SA ورودی را همتراز کنید.
ترافیک را روی میزبان IPsec ضبط کردید، دیدید بستههای ESP خارج میشوند، چیزی بازنگشت و نتیجه گرفتید که طرف دور خراب است. این ضبط از آن نتیجه پشتیبانی نمیکند. ESP یک جهت از گفتوگو را محافظت میکند و در لایه IP چیزی را تأیید نمیکند، پس نبودن ESP بازگشتی میتواند به همان آسانی یعنی برنامه چیزی برای گفتن نداشته، که یعنی تونل مرده است. پیش از سرزنش هر یک از دو طرف، تبادل درونی و وضعیت طرف دریافت را بخوانید.
افسانه: هر بستهٔ محافظتشده سزاوار پاسخ است
ESP یک پروتکل درخواست-پاسخ نیست. هر چیزی را که سیاست انتخاب کند رمزگذاری و احراز هویت میکند، و گیرنده آن بستهٔ درونی را بدون تولید بستهٔ خودش اعتبارسنجی، رمزگشایی و تحویل میدهد. پرسوجوی UDP که مقصد نادیده میگیرد، یا پژواک ICMP که سیاست ورودی دور میریزد، سکوت در هر دو جهت را به عنوان نتیجهٔ درست پدید میآورد. درمان آن سکوت به عنوان نقص انتقال شما را به شکار نقص شبکهای میفرستد که هرگز وجود نداشت.
آنچه یک ضبط یکطرفه واقعاً اثبات میکند این است که پشتهٔ فرستنده در آن نقطهٔ مشاهده چیزی را رمزگذاری کرده است. هیچ چیز دربارهٔ رسیدن، و هیچ چیز دربارهٔ قصد پاسخ دادن. پرسش سودمند "چرا پاسخی نیست" نیست، بلکه "گفتوگوی درونی چه چیزی باید پدید میآورد" است.
دو SA، دو SPI، یک گفتوگو
تداعیهای امنیتی IPsec یکطرفهاند، پس یک تبادل محافظتشدهٔ عادی شامل تداعی ورودی و تداعی خروجی با شناسههای جداگانه و وضعیت مستقل است. جستوجوی ترافیک بازگشتی بر اساس SPI بستهٔ خروجی از این رو خطای مقولهای است، زیرا هر پاسخی زیر SA خروجی خودِ همتا با SPI خودش سفر میکند. در عوض جفت را با انتخابگرهای ترافیک و نشانیهای همتا تطبیق دهید.
بازتولید کلید تصویر را هر بار برای چند ثانیه پیچیده میکند، چون وضعیت قدیمی و جایگزین میتوانند همپوشانی داشته باشند. اگر نشانه حوالی یک بازتولید کلید آغاز شده است، شناسههای تداعی و برچسبهای زمانی را با هم جمع کنید، نه فقط نام اتصال را.
گیرنده پیش از آنکه چیزی پاسخ دهد چه باید بکند
| Stage | What to look at | Wrong conclusion if skipped |
|---|---|---|
| Sender encrypts | outbound SA packet counter | "the tunnel is up" |
| Peer receives | inbound SA counter and replay window | "the peer is down" |
| Inner delivery | target host or service logs | "routing is broken" |
| Application replies | the app's own trace | "the reply was dropped" |
| Protected return | the peer's outbound SA | "ESP only works one way" |
هر ردیف بهطور مستقل شکست میخورد و هر شکست صاحب متفاوتی دارد، از این رو یک ضبط تنها نمیتواند آنها را از هم جدا کند. شمارندهٔ ورودی تنها شاهد مستقیم رسیدن است، زیرا بستهای که در احراز هویت یا بررسی تکرار شکست بخورد بدون هیچ پاسخی دور ریخته میشود. همتایی که شمارندهٔ ورودیاش تکان نخورده است، بنابراین هیچ اطلاعاتی دربارهٔ سیاستش به شما نمیدهد.
تحویل گامی جدا از رمزگشایی است. وضعیت میتواند معتبر باشد و بسته با این حال بعداً توسط سیاست ورودی یا مسیری که مقصد درونی را شامل نمیشود دور ریخته شود، پس بررسی کنید که آیا میزبان هدف متن روشن را دیده است، به جای فرض اینکه شمارندهٔ پاک یعنی بسته همانجا رفته که میخواستید.
ESP بومی UDP نیست
ESP بومی پروتکل IP 50 است که نه TCP است نه UDP و هیچ پورتی ندارد. بنابراین قاعدهٔ دیوار آتش که IKE را روی UDP 500 مجاز میکند هیچ چیزی دربارهٔ مسیر داده نمیگوید، و صافیای که پیرامون پورتها نوشته شده میتواند تونل را به مذاکره بگذارد و سپس هر چیزی را که درونش حمل میشود دور بریزد. مسیر داده را بهتنهایی و در همان حالتی که واقعاً مشاهده کردید بیازمایید.
پشت NAT شکل تغییر میکند: بار محافظتشده درون UDP سفر میکند، معمولاً روی پورت 4500، چنانکه RFC 3948 تعریف میکند. پیش از نوشتن هر قاعدهای حالت فعال را ثبت کنید، زیرا دستگاهی روی مسیر میتواند ESP بومی و ESP کپسولشده در UDP را کاملاً متفاوت رفتار دهد، و برخی جعبههای میانی یکی را مجاز میکنند و دیگری را دور میریزند.
شمارندههایی را بخوانید که به این رخداد تعلق دارند
روی میزبان strongSwan، swanctl --list-sas شمارندههای بسته و بایت هر تداعی را در هر دو جهت گزارش میکند، که برای جدا کردن "هرگز نرسید" از "رسید و پاسخ داده نشد" کافی است. در Linux، /proc/net/xfrm_stat شکستهای تجمعی مانند وضعیت گمشده، سیاست گمشده و خطاهای پروتکل را میشمارد. این مجموعها از زمان راهاندازی انباشته میشوند و به یک فضای نام شبکه تعلق دارند، پس عدد بزرگ هنوز انتساب نیست.
در فضای نام درست دو خوانش پیرامون پنجرهٔ رخداد بگیرید و اختلافها را مقایسه کنید، وگرنه خطاهای هفتهٔ گذشته را به بلیت امروز بعدازظهر میچسبانید. فضای نام و هر دو برچسب زمانی را در بلیت بنویسید تا خوانندهٔ بعدی بتواند مقایسه را بازتولید کند، نه اینکه به یک مجموع اعتماد کند.
مرحله را نام ببرید، نه مظنون را
نتیجهٔ سودمند میگوید بسته کجا ایستاد: هرگز دریافت نشد، دریافت و دور ریخته شد، تحویل شد اما بیپاسخ ماند، یا پاسخ داده شد و در راه بازگشت گم شد. هر یک از اینها به صاحبی متفاوت و فرمان بعدی متفاوتی اشاره میکند. "هیچ پاسخی از سرور VPN نیست" چهار نقص متمایز را در یک جمله فشرده میکند که ضبط هرگز آن را توجیه نکرد.
ضبطها را باریک نگه دارید و وضعیت خام هسته را بیرون از بلیتها نگه دارید، چون ممکن است مواد کلیدی را حمل کند که هیچ کاری بیرون از میزبان ندارد. اختلاف شمارندهها و برچسبهای زمانی بخشهایی هستند که ارزش سپردن به نفر بعد را دارند.