ESP پروتکل IP شماره 50 است، نه پورت TCP شماره 50: چه چیزی را مجاز کنیم
شماره‌های پروتکل و شماره‌های پورت فضاهای نام متفاوتی هستند. قاعده‌ای برای پورت TCP شماره 50 هیچ چیز را مجاز نمی‌کند و عبور NAT، ESP را به UDP 4500 منتقل می‌کند.
فرم‌های فایروال یک پورت TCP می‌خواهند و ورودی بدیهی 50 است. این ورودی هیچ چیز را مجاز نمی‌کند، چون ESP پروتکل IP شماره 50 است و شماره‌های پروتکل پورت نیستند. این دو فضای نام فقط اعداد صحیح کوچک را مشترک دارند و هیچ چیز دیگری، و این خطا تا زمانی که IKE تمام شود و ترافیک محافظت‌شده هرگز نرسد، نامرئی می‌ماند.
دو فضای نام که اعداد کوچک را مشترک دارند
سرآیند IP یک فیلد پروتکل دارد که نام چیزی را می‌گوید که بعد می‌آید: 6 برای TCP، 17 برای UDP، 1 برای ICMP، 50 برای ESP، 51 برای AH. سرآیند TCP یا UDP شماره‌های پورت را حمل می‌کند که یک فرایند را روی میزبان مقصد انتخاب می‌کنند. پروتکل 50 و پورت TCP 50 مقادیر بی‌ارتباطی هستند که یک کادر گفتگو می‌تواند آن‌ها را قابل تعویض نشان دهد.
به همین دلیل قاعدهٔ هدایت پورت نمی‌تواند ESP بومی را بیان کند. هیچ پورت مقصد ESP برای هدایت وجود ندارد و دستگاهی که فقط قواعد پورت را می‌فهمد، هیچ واژگانی برای این بسته ندارد. قاعدهٔ درست به‌جای آن پروتکل IP را نام می‌برد. هر کادر گفتگوی پورت ابزار اشتباهی برای این بسته است.
این سردرگمی نیمهٔ دومی هم دارد. وقتی بسته رمزنگاری شده است، هر چیزی درون آن مات است، از جمله سرآیند TCP اتصال اصلی. فایروالی که پورت‌های آن بسته را بررسی می‌کند، به سرآیند بیرونی نگاه می‌کند که در حالت بومی هیچ پورتی برای بررسی ندارد.
ESP بومی، سپس گزینهٔ کپسوله‌شده
ESP بومی مستقیماً به‌عنوان یک پروتکل IP حمل می‌شود که هم کارآمد است و هم به همان اندازه دشوار. کارآمد است چون سرآیند اضافه‌ای وجود ندارد، و دشوار است چون هر دستگاهی که ترجمهٔ نشانی و پورت انجام می‌دهد نمی‌تواند آن را دنبال کند. عبور NAT برای حل همین وجود دارد: بستهٔ ESP را درون UDP می‌پیچد تا مترجم پورت‌هایی برای بازنویسی داشته باشد.
| Form on the wire | How it is identified | What the firewall must permit |
|---|---|---|
| IKE negotiation | UDP with a destination port | UDP 500, and 4500 once traversal is detected |
| Native ESP | IP protocol 50 in the outer header | The protocol itself, with no port to name |
| ESP inside UDP | UDP 4500 carrying an ESP payload | The UDP port pair, which translation devices can track |
این دو شکل، استقرارهای جایگزین همان کانال داده هستند، نه لایه‌هایی از یک کانال. مجاز کردن ESP بومی شکل کپسوله‌شده را مجاز نمی‌کند و مجاز کردن UDP 4500 ترافیک بومی را مجاز نمی‌کند، بنابراین مجموعهٔ قواعد باید با استقرار بخواند نه اینکه تصادفی هر دو را بپوشاند.
تشخیص هم در اینجا مهم است. نقاط پایانی هنگام مذاکره بین شکل‌ها تصمیم می‌گیرند و تغییر معمولاً زمانی رخ می‌دهد که NAT بین آن‌ها تشخیص داده شود. بنابراین مسیری که پس از برپایی تونل تغییر می‌کند می‌تواند ترافیک را به فضای نامی ببرد که قواعد شما هرگز آن را نپوشانده بود.
بخوانید که اتصال واقعاً از کدام شکل استفاده می‌کند
از نقطهٔ پایانی بپرسید، نه اینکه از فایروال حدس بزنید. در لینوکس ورودی وضعیت گزارش می‌دهد که آیا انجمن از کپسوله‌سازی UDP استفاده می‌کند و کدام پورت‌ها درگیرند. ضبط بسته همان پرسش را از سیم پاسخ می‌دهد و هر دو سریع‌تر از خواندن مجموعهٔ قواعد و امیدوار بودن هستند.
ip xfrm state | grep -A3 encap
tcpdump -ni any 'ip proto 50 or udp port 4500'فرمان اول وقتی عبور NAT در کار است نوع کپسوله‌سازی را نشان می‌دهد و وقتی نیست هیچ چیز. دومی نشان می‌دهد کدام یک از دو شکل واقعاً از رابط می‌گذرد و این بحث‌ها دربارهٔ پیکربندی‌ای را که روی کاغذ درست به نظر می‌رسد پایان می‌دهد.
شواهد مخالف به همان گام تعلق دارد. قاعده‌ای که صفر تطابق گزارش می‌کند به شما می‌گوید بسته هرگز به آن نرسیده است و این مسئلهٔ مسیریابی یا انتخابگر است، نه فایروال.
سپس کانال کنترل را جداگانه تأیید کنید. IKE پورت‌ها و گزارش‌های خودش را دارد و مذاکرهٔ کامل‌شده بدون داده دقیقاً همان جدایی است که این مقاله دربارهٔ آن است.
قاعده را در فضای نام درست بنویسید
قاعدهٔ پروتکل و قاعدهٔ پورت دستورهای متفاوتی هستند، پس ابزار باید همانی را بیان کند که منظور شماست. در nftables تطبیق پروتکل صریح است و گزینهٔ کپسوله‌شده قاعدهٔ UDP خودش را می‌گیرد. دو قاعده را کنار هم نگه دارید تا این جفت در بازبینی دیده شود.
nft add rule inet filter input ip protocol esp accept
nft add rule inet filter input udp dport { 500, 4500 } acceptدر برابر وسوسهٔ گستردن هر یک از قواعد برای جبران یک تشخیص نادرست مقاومت کنید. مجاز کردن همه‌چیز برای پروتکل ESP روی هر رابط، یا مجاز کردن UDP از هر جایی به هر جایی، یک نشانه را درمان می‌کند و کنترلی را که می‌خواستید تنظیم کنید از بین می‌برد. جریان باریک پشتیبانی‌شده تقریباً همیشه کافی است، به‌محض اینکه شکل معلوم شود.
در پایان، وقتی تونل کار می‌کند و برنامه کار نمی‌کند، لایه‌ها را درست نگه دارید. بسته‌هایی که به دروازه می‌رسند هنوز به هدایت، مسیر بازگشت و سیاستی نیاز دارند که آن‌ها را بپذیرد و هیچ‌یک از این‌ها با قاعدهٔ ESP بیان نمی‌شود. پورت گمشده یک شکست مشخص را توضیح می‌دهد، نه هر شکست IPsec را. اصلاح قاعده و بررسی مسیریابی را دو نتیجهٔ جداگانه نگه دارید.
شکلی را که مشاهده کردید، قاعدهٔ پروتکلی را که افزودید و شمارنده‌ای را که بعداً دیدید ثبت کنید. سه خط، و نفر بعدی می‌تواند در یک دقیقه به‌جای یک بعدازظهر، خطای فضای نام را از خطای مسیریابی تشخیص دهد.