برنامهای که به نشانی VPN مقید شده همچنان از مسیر اشتباه استفاده میکند
سوکتی که به نشانی VPN مقید شده از مسیر پیشفرض معمول پیروی میکند. پیش از افزودن قواعد سیاست، مالکیت نشانی و جستوجوی آگاه از مبدأ را بررسی کنید.
برنامهای به نشانی VPN مقید میشود و اتصال همچنان از مسیر پیشفرض معمول خارج میشود. هیچ چیز در bind شکست نخورده است؛ همان کاری را کرده که bind انجام میدهد. مقید کردن سوکت به یک نشانی محلی، نشانی مبدأ را انتخاب میکند که هسته در سرآیند میگذارد. این کار مسیری نصب نمیکند و قاعده سیاستی ایجاد نمیکند که بستههای حامل آن مبدأ را به تونل مشخصی بفرستد.
بقیه این راهنما همان ترتیب بررسیای است که به کار میبرم، همراه با فرمانی که هر مشاهده را تولید میکند.
bind در واقع چه چیزی را تعیین میکند
bind یک نشانی محلی به سوکت اختصاص میدهد. سپس هسته همان جستوجوی مسیری را انجام میدهد که در غیر این صورت انجام میداد، مگر اینکه قاعدهای سیاستی تغییر دهد که آن جستوجو کدام جدول را میخواند.
به همین دلیل بسته میتواند با نشانی مبدأ VPN از یک واسط فیزیکی خارج شود. در طرف دیگر از محدوده خصوصی میرسد که شبکه هرگز آن را روی این مسیر انتظار نداشت، ترافیک بازگشتی مسیری برای برگشت ندارد و اتصال معلق میماند یا بازنشانی میشود.
مرجع سوکتهای IP در Linux معنای bind را مستند میکند. نیمه مسیریابی در ip-rule و ip-route زندگی میکند و اینها به دلیلی صفحههای راهنمای جداگانهاند.
تأیید کنید که نشانی به این فضای نام تعلق دارد
نشانیای که میتوانید به آن مقید شوید باید روی واسطی درون فضای نام شبکهای که برنامه در آن اجرا میشود وجود داشته باشد. نشانی همتا، نشانی دروازه یا نشانیای که فقط در فضای نام دیگری وجود دارد قابل مقید شدن نیست و فراخوانی با EADDRNOTAVAIL شکست میخورد.
ip -br addr show
ip netns identify <pid>
ss -tanp | grep <port>آن سه را در همان بافت برنامه اجرا کنید: همان فضای نام و در صورت امکان همان کاربر. نمودار net30 قدیمی مدرکی نیست بر اینکه توپولوژی فعلی شما کدام نشانی را به کلاینت داده است. واسطی را بخوانید که واقعاً فعال است.
جستوجوی آن مبدأ و مقصد را بخوانید
یک فرمان به پرسشی پاسخ میدهد که bind پاسخ نداد:
ip route get 203.0.113.10 from 10.8.0.2
ip rule showخط اول مسیری را چاپ میکند که بستهای از آن مبدأ به آن مقصد طی میکند، شامل واسط خروجی و مبدأ ترجیحی. اگر واسط فیزیکی را نام ببرد، bind و مسیر با هم اختلاف دارند و بسته با مبدأیی خارج میشود که مسیر نمیتواند به آن بازگردد.
سپس ip rule show میگوید آیا قاعدهای جدول دیگری را انتخاب میکرد. اولویتها اینجا مهماند، چون اولین قاعده منطبق برنده میشود و قاعدهای که همه چیز را بالاتر از قاعده شما میگیرد، قاعده شما را نامرئی میکند.
قاعده سیاست را فقط وقتی نصب کنید که طراحی همین باشد
مسیریابی مبتنی بر مبدأ طراحی عامدانه است، نه تعمیر برای یک برنامه. اگر صاحب سیاست میخواهد ترافیک زیرشبکه تونل از تونل استفاده کند، قاعده به پیکربندی او تعلق دارد نه به فرمانی یکباره روی لپتاپ شما.
شکل عملی یک جدول اختصاصی با مسیر پیشفرض از طریق تونل است، بههمراه قاعدهای که محدوده مبدأ VPN را به آن جدول میفرستد. استثناهایی را که طراحی نیاز دارد اضافه کنید، چون جدولی که فقط پیشفرض تونل دارد مقصدهایی را میگیرد که باید محلی بمانند یا از مسیر فیزیکی در دسترس باشند.
ip route add default dev tun0 table 100
ip rule add from 10.8.0.2 table 100 priority 100
ip route get 203.0.113.10 from 10.8.0.2با ip rule del و ip route flush table 100 برگردانید. هر چیزی که اینگونه اضافه شود با راهاندازی مجدد ناپدید میشود، مگر اینکه مدیر آن را بنویسد؛ این هم ویژگی ایمنی است و هم دلیلی برای نگه نداشتن تنها نسخه در تاریخچه شل شما.
با سه مشاهده بررسی کنید
مبدأیی را که برنامه درخواست کرد، مسیری را که جستوجو انتخاب کرد و مبدأیی را که سرور واقعاً دید ثبت کنید.
این سه میتوانند اختلاف داشته باشند و هر اختلاف به جای دیگری اشاره میکند. ثبت روی واسط تونل ثابت میکند بسته با مبدأ درست خارج شده است. ثبت روی واسط فیزیکی ثابت میکند از راه اشتباه خارج شده است. دید از سمت سرور تنها چیزی است که مسیر را سرتاسر ثابت میکند.
اگر برنامه گزینه مقید کردن به دستگاه یا حالت مسیریابی برای هر برنامه را ارائه میدهد، آن را مکانیزمی متفاوت با محدودیتهای متفاوت بدانید. تنظیمات ظاهراً مشابه همه به یک تصمیم هسته نمیرسند.