تشخیص تکه‌تکه‌سازی IKEv2 از مشکل زنجیره گواهی

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

دو سازوکار تکه‌تکه‌سازی، یک نشانه

IKEv2 افزونه تکه‌تکه‌سازی خود را دارد که در RFC 7383 تعریف شده و پیام‌های محافظت‌شده IKE را به پیام‌های IKE کوچک‌تر تقسیم می‌کند. طرف‌ها درباره این قابلیت مذاکره می‌کنند، و پیام توسط پیاده‌سازی IKE بازسازی می‌شود نه توسط لایه IP.

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

عبور از NAT متغیر سومی اضافه می‌کند، چون ESP آنگاه در UDP پیچیده می‌شود و بسته بیرونی بزرگ‌تر می‌شود در حالی که شبیه ترافیک معمولی UDP روی درگاه 4500 به نظر می‌رسد. مسیری که UDP را خوب عبور می‌دهد باز هم می‌تواند روی بسته‌ای که دیگر جا نمی‌شود شکست بخورد.

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

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

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

مسیر را عوض کنید، نه گواهی را

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

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

پیش از هر ویرایشی تبادل را اندازه بگیرید

اندازه زنجیره و اندازه مسیر را به دست آورید. هر دو عدد محدود می‌کنند که دست‌دادن چه می‌تواند بفرستد، و اندازه‌گیری هر دو ارزان است:

openssl crl2pkcs7 -nocrl -certfile chain.pem | openssl pkcs7 -print_certs -noout | grep -c subject
ls -l chain.pem
ping -M do -s 1400 198.51.100.7
ip -s link show eth0 | sed -n '1,6p'

دو مورد اول تعداد گواهی‌ها و اندازه پرونده را می‌دهند، که شاخص معقولی برای بزرگی پیام احراز هویت است. آزمون ping گزارش می‌دهد آیا بسته‌ای با آن اندازه از مسیر جان سالم به در می‌برد، و شمارنده‌های واسط نشان می‌دهند آیا تکه‌ها در سمت شما دور ریخته شده‌اند. در Windows آزمون معادل ping با پرچم do-not-fragment و اندازه صریح بار مفید است.

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

لایه‌ای را که واقعاً خراب است درست کنید

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

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

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