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

شمارنده شاهد است، نه سطر جدول

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

iptables -t nat -L POSTROUTING -v -n

ابتدا شمارنده کنار تطبیق رابط را بخوانید. اگر محدوده مبدأ درست و سمت خروجی نادرست باشد، اصلاح یک کلمه در همان قاعده است و نه یک قاعده کاملاً جدید.

نامی را پیدا کنید که هسته واقعاً ثبت می‌کند

پیش از نوشتن قاعده، دستگاه تونل را با نام شناسایی کنید و از فهرست رابط‌ها استفاده کنید نه از حافظه. در چیدمان OpenVPN پل‌شده، دستگاه معمولاً یک رابط tap است که سرور ساخته و نامش بخشی از پیکربندی محلی شماست، نه یک ثابت جهانی. تأیید کنید که در زمان بالا بودن تونل وجود دارد، چون دستگاهی که فقط بعد از اتصال کلاینت ظاهر شود آزمایش قبلی را شبیه مشکل قاعده می‌کند.

ip -brief link

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

قاعده را بر پایه دستگاه تونل بازنویسی کنید

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

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o tap0 -j MASQUERADE

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

خواندن زنجیره forward با شمارنده‌ها یک فرمان می‌خواهد و نیمی از احتمال‌های باقی‌مانده را پیش از دست زدن به قاعده دیگر کنار می‌گذارد.

چرا کارت فیزیکی هرگز تطبیق نمی‌خورد

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

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

آن را سرتاسر ثابت کنید و سپس ماندگارش کنید

یک کلاینت را بالا بیاورید و چیزی در شبکه محلی سرور را ping کنید؛ این مسیر هدایت را بدون هیچ ترجمه‌ای می‌آزماید. سپس چیزی عمومی بخواهید تا قاعده masquerade ناچار استفاده شود و شمارنده را یک بار دیگر بخوانید: باید برای این آزمایش حرکت کند نه برای قبلی. ثبت گرفته‌شده روی دستگاه تونل هم نشان می‌دهد قاب کجا ظاهر می‌شود و هم چه نشانی را حمل می‌کند.

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

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

مقالات مرتبط