بررسی واسط VPN لینوکس با ip link، لایه به لایه
پرچمها و شمارندهها تنها یک لایه را توصیف میکنند. پیش از آنکه نتیجه بگیرید تونل خراب است، ابتدا پیوند، سپس شمارندهها، سپس نشانیها و مسیرها را بخوانید.
آیکون کارخواه میگوید متصل است، واسط وجود دارد، و برنامه هنوز به هیچ چیز نمیرسد. این ترکیب رایج است، چون یک واسط مجازی میتواند باقی بماند در حالی که همتای دور آن، نشانیها یا مسیرهایش غایباند. ip link نخستین ابزار درست است و در همان حال سادهترین ابزار برای بیشتفسیر. پرچمها و شمارندهها یک لایه را توصیف میکنند و لایههای بالاتر از آنها مستقل شکست میخورند. همچنین ابزاری است که مردم وقتی میخواهند ثابت کنند تونل برپاست به آن استناد میکنند، همان ادعایی که این ابزار بهتنهایی از آن برنمیآید.
پیش از خواندن آیکون، واسط را بخوانید
شروع کنید با ip -details link show dev tun0 همانطور که در راهنمای ip-link مستند شده است، و بهجای نام متعارف، واسطی را بگذارید که کارخواه شما واقعاً دارد. پرچمها، نوع، MTU و شناسه واسط مشاهدات سودمندی هستند. بیان وضعیت یک واسط مجازی لازم نیست مانند نشانگر حامل یک کابل فیزیکی رفتار کند، پس UP را گزارهای درباره واسط بدانید، نه درباره تونل.
این تمایز گیجکنندهترین حالت را توضیح میدهد: واسطی که باقی میماند در حالی که طرف دور دوباره وصل میشود یا دستنیافتنی است.
تنظیمات ماندگاری میتوانند پیوند را دقیقاً برای همین نگه دارند تا اتصال دوباره آن را از نو نسازد، یعنی حضور به معنی سلامت نیست.
شمارندهها و درخواستی را اضافه کنید که باید از آنها استفاده کند
از نمای آمار پشتیبانیشده استفاده کنید ip -s link show dev tun0 و شمارش بسته و بایت را در هر دو جهت یادداشت کنید. سپس درخواستی بیخطر بسازید که باید از واسط بگذرد و جهت مربوط را مقایسه کنید. درخواستی که مسیر مستقیم برنامه دیگری را گرفته باشد این شمارندهها را تکان نمیدهد، و نکته تمرین همین است.
اگر شمارنده ارسال حرکت کند و شمارنده دریافت نکند، بسته خارج شد و چیزی بازنگشت. این مشکلی متفاوت از واسطی است که هرگز چیزی حمل نکرده است. اگر هر دو شمارنده حرکت کنند و برنامه هنوز شکست بخورد، نقص بالاتر از واسط است، و این پیشرفت است نه بنبست.
خوانش را دو بار بگیرید، یک بار پیش و یک بار پس، نه اینکه به یک عکس لحظهای اعتماد کنید.
نشانیها و مسیرها گامهای جداگانهاند
یک پیوند میتواند بدون پیشوند، پیکربندی حلکننده یا مسیری که برنامه نیاز دارد وجود داشته باشد. نشانی را با این بررسی کنید: ip address show dev tun0، سپس بررسی کنید مقصد با این کدام مسیر را انتخاب میکند: ip route get برای هدف واقعی. این سه مشاهده به سه پرسش متفاوت پاسخ میدهند و تنها آخری درباره ارسال است.
در IPsec ممکن است سیاست امنیتی و وضعیت انجمن هم مهم باشند، و هر طراحی IPsec بهصورت یک واسط ساده tun ظاهر نمیشود. جستوجوی دستگاه tun که هرگز قرار نبود وجود داشته باشد راهی سریع به نتیجهگیری نادرست است.
نام دقیق، فضای نام و زمان را همراه هر خروجی که نگه میدارید ثبت کنید، چون نامی که در ظاهر یکسان است در کانتینر دیگر یا نشست بازیابیشده زمینهای کاملاً متفاوت را نمایندگی میکند.
آنچه را شناسایی نکردهاید حذف نکنید
واسط ناشناس بهطور خودکار کهنه نیست. پیش از حذف هر چیزی مالک آن را مشخص کنید، و وقتی حذف واقعاً مورد نظر است از برچیدن مستند کارخواه یا پیکربندی مدیریتشده استفاده کنید. حذف یک تونل زنده برای دیدن اینکه چه میشود آزمونی است که به پرسشی پاسخ میدهد که کسی نپرسیده است.
اگر واسط به محیط کانتینر یا فضای نام شبکهای تعلق دارد که شما نساختهاید، مالک یک دستور فاصله دارد و ارزش دارد که نخست پیدا شود.
این احتیاط برای ip link set down هم صادق است، که برگشتپذیر به نظر میرسد و اغلب نیست.
آنچه بررسی باید برای شما بگذارد
یک بررسی خوب با چهار واقعیت پایان مییابد: نام و فضای نام واسط، پرچمها و MTU آن، اختلاف شمارندهها از یک درخواست واقعی، و مسیر و نشانیای که برنامه واقعاً نیاز دارد. وقتی اینها نوشته شوند، گام بعدی روشن است و به لایه مشخصی تعلق دارد. بدون آنها هر تغییر بعدی حدسی است همراه با طرح بازگشت.
این چهار واقعیت را با همان چهار واقعیت از یک نشست سالم مقایسه کنید. اگر نام و فضای نام یکی باشند اما اختلاف شمارندهها صفر باشد، درخواست هرگز به تونل نرسیده است. اگر اختلاف سالم باشد و مسیر جای دیگری را نشان دهد، تونل درست است و مسیریابی نه. همین مقایسه است که انبوهی از خروجی را به تصمیم تبدیل میکند.
خروجی را همراه تیکت نگه دارید، چون مقایسه بعدی تنها وقتی سودمند است که ببینید چه چیزی تغییر کرده است.
سپس حلقه را با آزمودن دوباره برنامه ببندید، چون واسط هرگز چیزی نبود که کاربر به آن اهمیت میداد.