eth0:0 یک برچسب است، نه یک دستگاه: تطبیق SNAT را درست کنید
شمارنده صفر یعنی قاعده نام رابطی را میآورد که نمیتواند وجود داشته باشد. دستگاه واقعی را بخوانید، تطبیق -o را درست کنید و بعد آدرس ترجمهشده را آگاهانه انتخاب کنید.
قاعدهای NAT که قرار بود به یک استخر کلاینت VPN آدرس عمومی خودش را بدهد، روی صفر بسته مانده است، در حالی که همان استخر همچنان با منبع اشتباه بیرون میرود. قاعده معمولاً در مورد آدرس اشتباه نمیکند؛ در مورد رابط اشتباه میکند. -o eth0:0 به دستگاهی اشاره میکند که وجود ندارد، چون eth0:0 برچسبی است که به آدرسی روی eth0 چسبیده است. نگاه کردن به شمارندهها سریعترین راه تأیید آن است، و اصلاح کوچکتر از آن است که بررسی نشان میدهد.
بررسی کنید هسته دستگاه را چه مینامد
پیش از هر تغییری دو نما را جداگانه بخوانید:
ip link show
ip address show dev eth0
ip route get 203.0.113.20
فهرست پیوندها رابطها را نشان میدهد. فهرست آدرسها ممکن است آدرس IPv4 دومی را نشان دهد که برچسب eth0:0 را دارد، و دستگاه آن آدرس هنوز eth0 است. دفترچه آدرس iproute2 برچسب را نامی برای آدرس میداند، نه پیوند دوم، و همان تمایز است که کل مسئله بر آن میچرخد.
تاریخ توضیحدهنده سردرگمی است. دستور قدیمی ifconfig eth0:0 واقعاً شبیه یک رابط تازه به نظر میرسید، و اسکریپتهای آن دوره هنوز به یکی اشاره میکنند. در سامانه امروزی، نام مستعار برچسبی روی یک آدرس است و هیچ چیز در مسیر مسیریابی یا netfilter آن را نقطه خروج جداگانه نمیداند.
بررسی کنید قاعده واقعاً با چه چیزی تطبیق خورد
شمارندهها را همراه فهرست قواعد بخوانید، نه از حافظه:
iptables -t nat -L POSTROUTING -v -n --line-numbers
قاعدهای که شمارنده بستهاش صفر میماند در حالی که ترافیک منطبق جریان دارد، ارزیابی نمیشود، و شرط رابط خروجی که eth0:0 را نام میبرد علت رایجی است. دستگاه خروجی که مسیر انتخاب کرده eth0 است، پس شرطی که نام دیگری را میجوید هرگز درست نمیشود، هرچند هسته کدام آدرس مبدأ را انتخاب کرده باشد.
شرط را به دستگاه واقعی تغییر دهید و برچسب را از آن بیرون بگذارید. اگر باید دو استخر کلاینت را که آن دستگاه را شریکاند از هم جدا کنید، آنها را با پیشوند مبدأ جدا کنید، نه با نام رابطی که نمیتواند وجود داشته باشد. دو قاعده با تطبیقهای -s بدون همپوشانی خوانا و آزمونپذیرند؛ یک قاعده با دستگاهی خیالی هیچکدام نیست. به هر قاعده توضیحی بدهید که استخر را نام ببرد، چون شش ماه بعد پیشوند تنها به کسی نمیگوید چرا آنجاست.
بررسی کنید کدام مسیر دستگاه را انتخاب کرد
NAT پسازمسیریابی پس از آن اجرا میشود که مسیر پیشتر رابط خروجی را انتخاب کرده، بنابراین رابط در قاعده باید همانی باشد که مسیر انتخاب کرده. از هسته مستقیم بپرسید با ip route get برای یک آدرس کلاینت نمونه و هم دستگاه و هم مبدأیی را که گزارش میکند بخوانید.
اگر پاسخ eth0 را نام ببرد، بخش رابط قاعده روشن است. اگر دستگاه تونلی را نام ببرد، بسته هرگز به قاعدهای که ویرایش میکنید نمیرسد و جستوجو به جدول مسیریابی و اولویتهایش میرود. قاعدهای که هرگز تطبیق نمیخورد چون بسته از جای دیگری رفته، در خروجی شمارنده همانند قاعدهای با دستگاه غلطنوشته دیده میشود. پیش از هر ویرایشی تأیید کنید کدامیک از این دو را دارید، چون دومی تغییر مسیریابی میخواهد نه تغییر متن.
منبع ترجمهشده را آگاهانه انتخاب کنید
وقتی دستگاه درست شد، آدرس مبدأ تصمیمی جداست. این فقط یک استخر IPv4 نمونه و یک آدرس مثال است:
iptables -t nat -A POSTROUTING -s 10.8.1.0/24 -o eth0 \
-j SNAT --to-source 203.0.113.20
نوشتن آدرس در --to-source باعث نمیشود کسی آن را به سمت شما مسیریابی کند. ارائهدهنده بالادست یا صاحب آدرس باید پاسخهای آن آدرس را به این میزبان برساند، و آدرس باید یکی از آدرسهایی باشد که مجاز به استفاده از آن هستید. اگر نباشد، قاعده تطبیق میخورد و ترجمه میکند و پاسخها باز هم جای دیگری میروند.
تغییر آدرس مبدأ همان تغییر پیوند بالادست نیست. وقتی نیاز واقعی مسیر فیزیکی دیگری است، سیاست مسیریابی باید نخست آن مسیر را انتخاب کند؛ SNAT سپس مبدأ را روی هر دستگاهی که سیاست انتخاب کرده بازنویسی میکند. افزودن برچسبهای بیشتر به eth0 نه مسیر را فراهم میکند نه مجوز را.
با اتصالی که همین حالا باز کردید تأیید کنید
اتصال کلاینت تازه باز کنید، نه اینکه اتصال موجود را دوباره به کار ببرید. ردیابی اتصال ترجمهای را که هنگام شروع جریان ثبت کرده نگه میدارد، پس یک نشست قدیمی میتواند همان آدرس مبدأ پیشین را به کار ببرد و قاعده تازه درست را خراب نشان دهد. افزایش شمارنده را ببینید و بعد منبع ترجمهشده را روی سیم یا در سر دور ببینید.
برای چند استخری که یک رابط را شریکاند، به هرکدام تطبیق مبدأ صریح و آدرس ترجمه خودش را بدهید، آنها را در پیکربندی مدیریتشده دیوار آتش نگه دارید و ترتیبی را که ارزیابی میشوند یادداشت کنید. بعد ثبت کنید چه چیزی را تأیید کردید: دستگاه از ip route get، شمارندهای که حرکت کرد، و منبعی که طرف دور دید. آن ثبت به گزارش بعدی پاسخ میدهد بدون تکرار سردرگمی نام مستعار.