اجرای L2TP بدون IPsec روی Linux: xl2tpd، pppd و NAT

L2TP ساده همان PPP درون یک پاکت است و نه چیز دیگری. قاب‌های شما را حمل می‌کند؛ آن‌ها را رمزنگاری نمی‌کند و اثبات نمی‌کند چه کسی در طرف دیگر نشسته است، و همین دلیل است که تقریباً هر استقراری IPsec را زیر آن می‌گذارد. دلایل صادقانه برای اجرای نسخه برهنه هنوز وجود دارد: یک میز آزمایشگاه، یک گام مهاجرت، یا پیوندی که از قبل درون مسیر محافظت‌شده دیگری قرار دارد.

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

سه فایل کار را تقسیم می‌کنند

xl2tpd اتصال کنترلی را پایان می‌دهد و هر نشست را به یک دیمن PPP تحویل می‌دهد، بنابراین پیکربندی میان دو برنامه پخش می‌شود که هرگز فایل‌های یکدیگر را نمی‌خوانند. شنونده در /etc/xl2tpd/xl2tpd.conf قرار دارد، درون بخش [lns default] که مخزن نشانی‌ها را با ip range، سمت سرور را با local ip و تحویل به PPP را با pppoptfile نام می‌گذارد. require authentication = yes را روشن کنید، length bit و flow bit را فعال بگذارید، و مخزنی برگزینید که هیچ چیز دیگری روی میزبان از آن استفاده نمی‌کند.

سیاست PPP به همان فایلی تعلق دارد که این گزینه نام می‌برد، معمولاً /etc/ppp/options.xl2tpd: auth، رد برای pap، chap و mschap، require-mschap-v2، MTU و MRU برابر 1460، و نشانی DNS که کلاینت پس از بالا آمدن پیوند به آن دسترسی دارد. اعتبارنامه‌ها باز هم فایل سومی هستند، /etc/ppp/chap-secrets، که در آن فیلد دوم باید با نام بخش LNS بخواند و فیلد چهارم می‌تواند نشانی مشخصی از مخزن را تثبیت کند.

چرا تونل وصل می‌شود و بعد گیر می‌کند

قاب Ethernet با اندازه 1500 بایت در مسیری جا نمی‌شود که از پیش بایت‌هایی را صرف سرآیندهای خود می‌کند. سرآیند بیرونی IPv4 هزینه 20 دارد، UDP هزینه 8، و سرآیند L2TP حدود 12، که 1460 را برای PPP و بار آن باقی می‌گذارد. اعلام همین عدد کوچک‌تر در PPP است که مانع قطعه‌قطعه شدن بسته‌های بزرگ یا افتادن خاموش آن‌ها جایی در میانه می‌شود.

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

یک درگاه دو گفت‌وگو را حمل می‌کند

UDP 1701 زیر هر دو نیمه پروتکل قرار دارد، و همین یک واقعیت بیش از هر بخش دیگری از راه‌اندازی قواعد دیوار آتش را می‌شکند. نخست درخواست آغاز اتصال کنترل و پاسخش می‌آیند؛ درخواست نشست و تأییدیه‌ای که پس از آن می‌آیند چیزی بیش از جفت شناسه برقرار نمی‌کنند. سپس PPP کار را می‌گیرد: کنترل پیوند، بعد احراز هویت، بعد پروتکل کنترل IP برای توافق نشانی‌ها. هر مرحله واژگان خودش را در گزارش دارد و هیچ‌کدام خود را به‌عنوان شکست L2TP اعلام نمی‌کند.

خواندن یک ضبط دقیقاً به همین ترتیب می‌گوید کدام مرحله شکست خورده است، و شکست احراز هویت PPP با ویرایش xl2tpd درست نمی‌شود. درگاه مشترک شکست رایج دیگری را توضیح می‌دهد: قاعده‌ای که فقط نخستین بسته‌های یک جریان را مجاز می‌کند اجازه می‌دهد نشست برقرار شود و سپس انتقال را مسدود می‌کند. 1701 را برای کل گفت‌وگو، در هر دو جهت، مجاز کنید.

کارآمد کردن تونل: ارسال مجدد و NAT

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

روی سرور، ارسال مجدد را با sysctl -w net.ipv4.ip_forward=1 فعال کنید، مخزن را با iptables -t nat -A POSTROUTING -s 10.44.0.0/24 -o eth0 -j MASQUERADE ترجمه کنید، سپس ترافیک خروجی تونل را با قاعده FORWARD برای -i ppp0 -o eth0 و ترافیک بازگشتی را با قاعده آینه‌ای به‌همراه -m state --state RELATED,ESTABLISHED بپذیرید. این قواعد را در میان راه‌اندازی‌های دوباره ماندگار کنید، زیرا سروری که بدون آن‌ها برمی‌گردد دقیقاً مانند پیکربندی خراب L2TP به نظر می‌رسد.

رسیدن به LAN خود سرور کار دیگری است: یک مسیر بازگشت برای مخزن روی روتر LAN اضافه کنید، یا proxy ARP روی سرور. پنهان کردن کلاینت‌ها پشت NAT وقتی چیزی درون LAN باید مستقیماً به آن‌ها نشانی بدهد، فقط نشست اشکال‌زدایی دومی را برای بعد برنامه‌ریزی می‌کند.

پشته برهنه چه نمی‌کند و چگونه بررسی کنیم

هیچ بخشی از این پشته قاب‌های PPP را رمزنگاری نمی‌کند، و هیچ چیز در آن طرف دور را به‌عنوان سروری که واقعاً برگزیده‌اید احراز هویت نمی‌کند. MS-CHAPv2 مبادله اعتبارنامه را از شنونده‌ای که فقط تماشا می‌کند محافظت می‌کند، اما مهاجمی که در مسیر قرار گرفته باز هم می‌تواند در نشست دخالت کند. کلاینت بومی Windows تنها همراه با IPsec امکان L2TP را می‌دهد، پس Linux، میان‌افزار روترها و کلاینت‌های شخص ثالث را به‌عنوان همتایان خود در نظر بگیرید. پیکربندی برهنه را پله‌ای تشخیصی بدانید، هرگز جایی که باید ایستاد.

به ترتیب ثابت بررسی کنید: xl2tpd -D را در پیش‌زمینه اجرا کنید، گزارش را برای مرحله PPP بپایید، نشانی تخصیص‌یافته را از ip addr در هر دو سر بخوانید، سپس UDP 1701 را ضبط کنید تا تأیید شود داده‌ها پس از برپایی نشست جریان دارند. اگر هر چهار مورد جور باشند و ترافیک هنوز شکست بخورد، ایراد در مسیریابی، NAT یا MTU است نه خود L2TP.