L2TP، GRE یا IPsec: کدام لایه باید نشست را حمل کند؟
L2TP نشستهای PPP را حمل میکند، GRE بستههای مسیریابیشده را، و IPsec ترافیک انتخابشده را محافظت میکند. به هر لایه یک کار بدهید و هر یک را جداگانه بررسی کنید.
هرگاه L2TP، GRE و IPsec در یک یادداشت طراحی کنار هم قرار میگیرند، دو پرسش در هم میپیچند: کدام نشست را حمل میکنم و کدام لایه از آن محافظت میکند؟ اگر پاسخ اول اشتباه باشد، همه چیز در پاییندست درونی سازگار میماند در حالی که مسئله اشتباه حل میشود — یک لایه رویی مسیریابیشده که آنجا ساخته شده که کاربران باید شمارهگیری میکردند، یا یک متمرکزکننده دسترسی شمارهگیری بهجای دروازه سایت به سایت. برگه کار زیر این تمایز را پیش از ورود کسی به دستگاه تحمیل میکند. آن را به ترتیب پر کنید و هر سطر به چیزی تبدیل میشود که میتوانید جداگانه بیازمایید.
از نشست شروع کنید، نه از فهرست پروتکلها
کاربر راه دوری که یک نشست PPP دارد و یک لایه رویی مسیریابیشده میان دو دروازه، دو رابطه شبکهی متفاوتاند، حتی وقتی هر دو در نهایت در IPsec پیچیده شوند. اولی یک پیوند بهازای هر کاربر را پایان میدهد و به تخصیص نشانی، احراز هویت یک شخص یا دستگاه، و سیاستی نیاز دارد که نام شبکههای داخلی قابل دسترس آن کاربر را ببرد. دومی بستهها را میان سایتهایی که کسی به آنها شمارهگیری نمیکند هدایت میکند.
یک جمله بنویسید که مشخص کند کدام یک از این دو را میسازید، سپس آن را چنان بخوانید که گویی خودتان باید آن را بهرهبرداری کنید. اگر جمله به واژه «و» نیاز دارد، هر دو را میسازید و برگه به دو ستون نیاز دارد نه یک ستون سازشی که به هر کدام نیمهخدمت میکند. اگر کاربری را نام میبرد اما هیچ استخر نشانیای ندارد، یا پیشوندی را اما هیچ سیاست هدایتی را، جمله هنوز ناقص است. جملهبندی بوروکراتیک به نظر میرسد، اما ارزانترین جایی است که طرحی را بگیرید که وگرنه یک بلیت پشتیبانی آن را کشف میکند.
به هر لایه دقیقاً یک کار بدهید
L2TPv2 نشستهای PPP را میان دو نقطه انتهایی خود حمل میکند. PPP مذاکره پیوند و، هنگامی که مذاکره شود، احراز هویت کاربر را اجرا میکند؛ L2TP هیچ رمزنگاریای نمیافزاید، بنابراین یک دیمن لخت L2TP هیچ بخشی از رابطه امنیتی IPsec را پیادهسازی نمیکند و تنها به درون پیوندی تعلق دارد که از پیش به آن اعتماد دارید.
GRE یک کپسولهسازی میان دو نشانی است. بستههای لایه شبکه را روی یک لایه رویی منطقی حمل میکند و بهتنهایی نه محرمانگی میدهد نه هویت همتای احرازشده. این نقص نیست: سرآیند ساده طراحی شده تا پردازشش روی سختافزار ارسال ارزان بماند. پیامد آن است که GRE به پرسش «چگونه این بسته را میان دو نشانی جابهجا کنم» پاسخ میدهد و به هیچ چیز دیگر — دقیقاً همان پرسشی که باید از آن بپرسید.
در نتیجه IPsec لایهای میماند که ترافیک را انتخاب میکند، همتاها را احراز میکند و آنچه را که به محافظت از آن مأمور شده رمز میکند. اینکه از کدام ترافیک محافظت میکند تصمیمی پیکربندی است که باید با کپسولهسازیای که نقاط انتهایی واقعاً تولید میکنند بخواند، زیرا سیاستی که برای نشانی بیرونی GRE نوشته شده با سیاستی برای پیشوندهای درونی رفتار متفاوتی دارد. مشخصات GRE بار مفید، سرآیند GRE و پروتکل تحویل بیرونی را آشکارا جدا نگه میدارد و سیاست شما به همان جدایی نیاز دارد.
| Layer | Its one job | What it never does |
|---|---|---|
| PPP | Link negotiation, optional user authentication, address assignment | Protect traffic between gateways |
| L2TPv2 | Carry the PPP session between two endpoints | Encrypt or authenticate peers |
| GRE | Encapsulate network-layer packets between two addresses | Hide or authenticate the payload |
| IPsec | Authenticate peers and encrypt selected traffic | Carry a dial-in user session by itself |
مسیر بسته را پیش از پیکربندی بنویسید
یک بسته بردارید و هر سرآیندی را که افزوده میشود به ترتیب افزودهشدن فهرست کنید و دستگاهی را که آن را میافزاید نام ببرید. برای کاربر شمارهگیری معمولاً PPP درون L2TP درون IPsec است؛ برای لایه رویی سایتها بسته IP درونی درون GRE درون IPsec. اگر دو دستگاه همان سرآیند را بیفزایند، یک حلقه یا یک تونل تکراری دارید و هیچ ویرایش سیاستی آن را درست نمیکند.
همان فهرست MTU را روشن میکند، زیرا اندازه درونی قابل استفاده همان MTU مسیر اندازهگیریشده منهای سرآیندهایی است که همین حالا برشمردید و هیچ چیز دیگر. عددی را از پست انجمن کپی نکنید: سرباری IP بیرونی، UDP و ESP را جمع بزنید، سپس GRE یا L2TP، سپس PPP هر جا که اعمال میشود، و آن را از MTU مسیری که واقعاً اندازه گرفتید کم کنید. نشانههایی که فقط در انتقالهای بزرگ ظاهر میشوند، یا نشستهایی که برقرار میشوند و سپس در نخستین پاسخ بزرگ میمیرند، معمولاً به همین جمع زدهشده با حدس برمیگردند.
هر لایه را جداگانه بررسی کنید، از بیرون به درون
بررسیها را به ترتیب اجرا کنید و در نخستین بررسی شکستخورده بایستید. هر سطر به پرسش متفاوتی پاسخ میدهد، بنابراین یک شکست به یک ستون از برگه اشاره میکند نه به اینکه تونل خراب است.
ip xfrm state # is the IPsec SA up?
ip -s link show gre1 # does the overlay interface carry packets?
ip route get 10.20.0.5 # does the inner prefix route where you think?
ss -lun | grep -E "1701|4500" # are the L2TP and NAT-T listeners bound?
روی جعبه سیسکو معادل وابسته به نقش است و نحو دقیق به پلتفرم و نسخه بستگی دارد: show crypto session برای همتاهای IPsec، شمارندههای رابط برای رابط GRE یا تونل، و بررسی VPDN یا PPP برای نقش شمارهگیری. مجموعه فرمانی که PPP را پایان میدهد چیزی درباره پشتیبانی GRE ثابت نمیکند، و رابط GRE کارآمد چیزی درباره سرویس PPP ثابت نمیکند، پس نقشی را بررسی کنید که واقعاً پیکربندی کردهاید نه نقش داخل نمودار.
هر خروجی را کنار سطر برگهی مربوط به آن ثبت کنید. یادداشتهایی که هنگام فعال بودن عیب گرفته میشوند از توپولوژیای که بعداً از حافظه بازرسم میشود ارزشمندترند.
برچیدن را مرتب کنید، سپس دوباره بررسی کنید
برچیدن به یک دلیل در ترتیب معکوس اجرا میشود: ترافیک محافظتشده را پیش از حذف کپسولهسازیای که سیاست برایش نوشته شده از سیاست IPsec بیرون آورید، وگرنه سیاست همچنان به رابطی اشاره میکند که دیگر وجود ندارد و بارگذاری پیکربندی بعدی جایی شکست میخورد که بیربط به نظر میرسد. در لینوکس یعنی حذف ورودیهای وضعیت و سیاست پیش از رابط تونل؛ روی مسیریاب یعنی حذف ورودی نقشه رمز یا پروفایل پیش از تونل.
پس از بازسازی، چهار مشاهده پذیرش را یکییکی تکرار کنید: دسترسی بیرونی، یک انجمن IPsec برقرارشده، یک نشست PPP برقرارشده در جایی که طرح یکی دارد، و هدایت درونی به یک نشانی مقصد واقعی. یک چراغ سبز دلیلی برای سه مورد دیگر نیست، و همین شکاف عیبی است که در تولید بیشتر دوام میآورد — تونلی که بالا، رمزشده و بیهدایت است چون مسیر درونی هرگز افزوده نشد.
برگه پرشده را کنار پیکربندی دستگاه نگه دارید. هر ستونی که نمیتوانید پر کنید لایهای است بدون کار تعیینشده، و لایهای بدون کار تعیینشده معمولاً لایهای است که نباید در پشته باشد.