مسیر به‌خاطر بیت‌های میزبان رد شد؟ پیشوند موردنظر را پیدا کنید

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

تجزیه‌کننده واقعاً از چه شکایت دارد

مقصدی که به‌صورت آدرس به‌همراه ماسک نوشته می‌شود باید شبکه‌ای را توصیف کند، و شبکه با بیت‌های میزبان صفر شروع می‌شود. وقتی آدرسی که می‌دهید هنوز مقداری در بخش میزبان دارد، این جفت درونی ناسازگار است: 172.20.130.0 مرتب به‌نظر می‌رسد چون با صفر تمام می‌شود، اما صفر در هشتم چهارم تنها چیز مهم نیست. هشتم سوم همانی است که اینجا بیت‌های سرگردان دارد.

ابزارها این ناسازگاری را متفاوت مدیریت می‌کنند. تجزیه‌کننده‌های سخت‌گیر خط را رد می‌کنند و بیت‌های میزبان را نام می‌برند. تجزیه‌کننده‌های آسان‌گیر آدرس را ماسک می‌کنند و چیزی نصب می‌کنند که شما نخواسته‌اید، که بدتر است، چون پیکربندی اکنون محدوده‌ای را مسیریابی می‌کند که هرگز قصدش را نداشتید. ماژول ipaddress در Python انتخاب را مستقیم نشان می‌دهد: تجزیهٔ سخت‌گیرانهٔ شبکه خطا می‌دهد و strict=False بیت‌های میزبان را ماسک می‌کند. کلاینت شما ممکن است بین نسخه‌ها سخت‌گیر، آسان‌گیر یا ناسازگار باشد، پس پیام را بخوانید نه اینکه به یک عادت اعتماد کنید.

مثال را دستی انجام دهید

تونلی را در نظر بگیرید که باید با ماسک /20 به 172.20.130.0 برسد. /20 چهار بیت از هشتم سوم قرض می‌گیرد، بنابراین آن هشتم فقط در گام‌های 16 شمرده می‌شود: 0، 16، 32 و به‌همین ترتیب تا 240. مقدار 130 بین 128 و 143 می‌افتد، یعنی شبکهٔ دربرگیرنده از 172.20.128.0 شروع می‌شود، نه از 172.20.130.0 با صفرکردن آخرین هشتم.

در نوشتار، بلوک از 172.20.128.0 تا 172.20.143.255 می‌رود و 4,096 آدرس دارد. دادن همان مقادیر به تجزیه‌کنندهٔ غیرسخت‌گیر جایگزینی را نشان می‌دهد که به‌جای شما انجام می‌داد:

$ python3 -c "import ipaddress; n=ipaddress.ip_network('172.20.130.0/20', strict=False); print(n, n.num_addresses)"
172.20.128.0/20 4096

تصمیم بگیرید واقعاً کدام مقصد را می‌خواستید

خط ردشده معمولاً یکی از سه نیت را پنهان می‌کند و تنها شما می‌توانید انتخاب کنید. اگر تونل به کل بلوک نیاز دارد، 172.20.128.0/20 را بنویسید، آدرس شبکهٔ متعارف. اگر تونل فقط به بخش 130 نیاز دارد، ماسک اشتباه بود و 172.20.130.0/24 شکل صادقانه است. اگر هدف یک ماشین واحد است، مسیر میزبان IPv4 برابر /32 است و هیچ حساب ماسکی در کار نیست.

هر یک از این‌ها مقدار متفاوتی از ترافیک را مجاز می‌کند، و این دلیل واقعی گسترش‌ندادن ماسک تا خاموش‌شدن شکایت است. /16 خط را تقریباً همه‌جا می‌پذیرد و ترافیک را به مقاصدی می‌فرستد که هرگز نمی‌خواستید از تونل عبور دهید. باریک‌ترین پیشوندی را که با نیت سازگار است بنویسید، سپس آن را با پرش بعدی که انتظار دارید تأیید کنید، نه با سکوت تجزیه‌کننده.

چرا ارسال هرگز راه‌حل نبود

مسیر ردشده هرگز به مسیر ارسال نمی‌رسد، پس تغییر net.ipv4.ip_forward نمی‌تواند نتیجه را عوض کند. آن تنظیم بعداً اهمیت دارد، وقتی میزبان باید بسته‌ها را بین رابط‌ها عبور دهد، و روشن‌کردن آن پیش از درست‌بودن جدول فقط مرحلهٔ بعدی شکست را تغییر می‌دهد.

دو چیز دیگر اغلب در همان نقطه سرزنش می‌شوند. ممکن است مسیر پذیرفته شود و باز هم به مسیری مشخص‌تر ببازد، و یک قاعدهٔ دیوار آتش ممکن است ترافیک را پس از جست‌وجوی درست دور بریزد. مراحل را جدا نگه دارید: نحو، نصب، انتخاب، فیلترکردن. کار روی مرحلهٔ اشتباه مولد به‌نظر می‌رسد چون هر تغییر چیزی را دوباره شروع می‌کند.

مسیر نصب‌شده و مسیری که می‌برد را بررسی کنید

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

یک آدرس عضو و یکی بیرون از بلوک را بپرسید تا مقایسه معنادار باشد، نه یک خط دلگرم‌کنندهٔ تنها:

ip -4 route show 172.20.128.0/20
ip -4 route get 172.20.140.10
ip -4 route get 172.20.200.10

پرس‌وجوی سوم اگر پیشوندتان درست باشد باید بیرون از تونل بیفتد، و اگر نیفتد، مسیری که ساخته‌اید پهن‌تر از آن است که فکر می‌کنید. پیش از دست‌زدن به تنظیم بعدی یادداشت کنید که پیشوند قرار بود چه چیزی را بپوشاند، چون مسیری که تجزیه می‌شود و راهی که کار می‌کند دو مشاهدهٔ جدا باقی می‌مانند.