چرا L2TP/IPsec علاوه بر IPsec به UDP 1701 نیاز دارد

دیوارهای آتشی که IKE و ESP را مجاز می‌کنند اما UDP 1701 را نه، اتصال‌های L2TP را به شکلی قطع می‌کنند که شبیه مشکل اعتبارنامه است. دلیل این است که L2TP پروتکل دومی است که درون پروتکل اول سفر می‌کند. IPsec تبادل را حمل و تأیید می‌کند و L2TP تونل خود را روی UDP 1701 اجرا می‌کند که پشته محلی هنوز باید آن را تحویل دهد. دانستن این‌که هر سرآیند کجا ظاهر می‌شود توضیح می‌دهد کدام دستگاه به کدام قاعده نیاز دارد.

دو پروتکل، دو مجموعه پورت

اتصال L2TP/IPsec از IKE روی UDP 500، عبور NAT روی UDP 4500 در جایی که ترجمه وجود دارد، و ESP به‌عنوان پروتکل IP 50 در جایی که وجود ندارد استفاده می‌کند. خود L2TP یک پروتکل تونل روی UDP 1701 است و پس از آن اجرا می‌شود که IPsec طرف مقابل را تأیید کرده باشد. دو نیمه به شکل‌های متفاوت شکست می‌خورند و خطوط گزارشی که از آن‌ها خبر می‌دهند از اجزای متفاوت می‌آیند. مجموعه قواعدی که فقط نیمه اول را پوشش می‌دهد اتصالی می‌سازد که مذاکره می‌کند و سپس در مرحله تونل می‌میرد.

شماره پورت‌ها نقاط پایانی انتقال را توصیف می‌کنند و ESP اصلاً پورت نیست. به همین دلیل یک رابط دیوار آتش که فقط قواعد TCP و UDP عرضه می‌کند نمی‌تواند سیاست کامل IPsec را بیان کند. پروتکل 50 باید به‌عنوان پروتکل مجاز شود و قاعده‌ای که فقط UDP را ذکر می‌کند هرگز با آن مطابقت نخواهد داشت.

پوسته پورت را توضیح می‌دهد

روی سیم، اتصال L2TP/IPsec معمولاً IKE روی 500 و ESP کپسوله‌شده روی 4500 را نشان می‌دهد. سرآیند UDP 1701 درون بار مفید محافظت‌شده قرار دارد، به همین دلیل یک ضبط روی رابط بیرونی آن را نشان نمی‌دهد. میزبان محلی هنوز باید آن دیتاگرام را به دیمن L2TP تحویل دهد و تحویل پس از کپسول‌گشایی رخ می‌دهد. بنابراین قاعده 1701 متعلق به دیوار آتش خود نقطه پایانی است، حتی وقتی هیچ جعبه میانی هرگز پورت را نمی‌بیند.

ترتیب پردازش بیشتر سرگردانی را توضیح می‌دهد. اگر پشته سیاست IPsec را پیش از فیلتر میزبان اعمال کند، بسته کپسول‌گشایی‌شده L2TP به‌عنوان UDP 1701 تطبیق داده می‌شود؛ اگر ترتیب برعکس باشد، پورت‌های بیرونی چیزی است که مجموعه قواعد می‌بیند. هر دو رفتار در عمل وجود دارد، به همین دلیل مجموعه قواعد یکسان به نظر می‌رسد روی یک بستر کار می‌کند و روی دیگری شکست می‌خورد.

مسیر را به ترتیب بررسی کنید

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

sudo tcpdump -ni eth0 'udp port 500 or udp port 4500'
sudo nft list ruleset | grep -i -A2 1701
sudo ss -lunp | grep 1701

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

آنچه اسکن پورت نمی‌تواند نشان دهد

اسکن بیرونی UDP 1701 روی سروری که درست پیکربندی شده معمولاً چیزی گزارش نمی‌کند و این نتیجه مورد انتظار است. پورت به اینترنت باز نیست؛ تنها پس از آن به آن می‌رسید که IPsec طرف مقابل را تأیید کرده باشد. برخورد با نتیجه بسته به‌عنوان خرابی به باز کردن پورتی می‌انجامد که باید بسته بماند. اسکن نمی‌تواند درون تونل را ببیند، همان‌قدر که نمی‌تواند ترافیک برنامه را ببیند.

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