میزبان به همتای IPsec میرسد، کانتینر Docker نه
کانتینر روی شبکه پل از منبع دیگری استفاده میکند و از راه ارسال جلو میآید، پس تونل میزبان چیز زیادی اثبات نمیکند. پیش از راهاندازی دوباره Docker انتخابگرها را بررسی کنید.
از ماشین Linux به میزبان دور ping میفرستید و پاسخ میدهد، پس تونل کار میکند. کانتینر کنار شما هنوز به پایان زمان میرسد و گام طبیعی بعدی راهاندازی دوباره Docker است. کانتینر روی شبکه پل معمولاً با نشانی مبدأ دیگری آغاز میشود و از راه ارسال جلو به میزبان وارد میشود نه از راه مسیر خروج خود برنامهٔ میزبان، بنابراین آزمون موفق بستهٔ دیگری را اندازه گرفت. برای تونل strongSwan مبتنی بر سیاست، مسیر معمولی به زیرشبکهٔ دور کافی نیست وقتی بستهٔ ارسالشده با سیاست نصبشدهٔ IPsec همخوانی ندارد.
راهنمای زیر یک مقصد را در دو منبع دنبال میکند و پیش از تغییر هر چیزی وضعیت را میخواند.
با یک مقصد و دو منبع آغاز کنید
نخست سرویسی شناختهشده بر پایهٔ IP برگزینید تا همزمان DNS را عیبیابی نکنید. سه واقعیت را ثبت کنید: پیشوند پل کانتینر، نشانی مبدأ درخواست میزبانی که کار کرد، و انتخابگرهای ترافیک محلی و دور توافقشده برای تونل. این سه عدد تقریباً هر حالت این نشانه را توضیح میدهند.
سپس درخواست ناموفق را از درون کانتینر تکرار کنید و منبعی را که واقعاً به کار میبرد بگیرید. اگر آن نشانی در انتخابگر محلی پوشش نداشته باشد، نتیجه را از پیش میدانید و هیچ بازسازی کانتینر آن را تغییر نمیدهد.
پیش از دست زدن به Docker سیاستها را بخوانید
بررسیهای فقطخواندنی میزبان تصمیمهای مسیریابی، پایگاهدادهٔ سیاستها و قواعدی را که میان آنها انتخاب میکنند پوشش میدهند:
ip rule show
ip route show table all
ip xfrm policyفهرست سیاستها انتخابگرها و جهت را بدون نیاز به خروجی وضعیت IPsec پر از مواد کلید نشان میدهد، از این رو چسباندنش در یک تیکت بیخطر است. به دنبال انتخابگر محلی بگردید که نشانی میزبان را پوشش میدهد ولی پیشوند پل را نه. همپوشانی را نیز بررسی کنید: مسیر کانتینری که مقصد دور را محلی میپندارد هرگز بستهٔ ارسالشدهٔ مورد انتظار را تولید نمیکند و تونل سرزنش میشود. آن فهرست را کنار نشانی مبدأ کانتینر نگه دارید، زیرا این دو با هم تمام مقایسهاند.
اگر پیشوند کانتینر نیست، بایستید و پیش از ویرایش هر چیز دیگری معماری را تعیین کنید. باقی این راهنما فرض میکند که بر سر این که کدام نشانی مبدأ باید در شبکه دیده شود توافق کردهاید.
پالایش و ترجمه را به ترتیب بررسی کنید
دیوار آتش پل Linux در Docker میتواند ارسال جلو را مستقل از IPsec مسدود کند. با پشتوانهٔ iptables مسیر FORWARD و تصمیمهای DOCKER-USER را بررسی کنید و به یاد داشته باشید قاعدهای که پس از حکمی پیشین افزوده شود شاید هرگز اجرا نشود. پشتوانهٔ nftables به گونهای دیگر یکپارچه میشود، پس فقط به این دلیل که نمونهای با iptables آن را چنین نامیده زنجیرهٔ DOCKER-USER نسازید؛ بررسی کنید daemon شما در واقع کدام پشتوانه را به کار میبرد.
سپس ترجمهٔ مبدأ را بررسی کنید. قاعدهٔ گستردهٔ MASQUERADE میتواند بستهای را که پیشتر با انتخابگر IPsec همخوان بود به بستهای تبدیل کند که دیگر همخوان نیست، و خرابی دقیقاً مانند مشکل مسیریابی به نظر میرسد. راهنمای ارسال جلو strongSwan استثنای NAT لازم پیش از چنین ترجمهای را برای ترافیکی که از پیش با سیاست همخوان است مستند میکند.
این استثنا راهی برای افزودن منبع کانتینری پوششنداده به تونل نیست. تنها ترافیکی را حفظ میکند که از پیش با طراحی سازگار است، پس نخست پرسشهای انتخابگر و مسیر بازگشت را حل کنید، سپس NAT و پالایش را با پاسخ هماهنگ کنید. اگر به جای آن استثنا را گسترش میدهید، چیزی که باید تغییر کند انتخابگر است نه قاعدهٔ NAT.
سپس تصمیم بگیرید مسیریابیشده یا ترجمهشده
زیرشبکهٔ کانتینری مسیریابیشده نیازمند آن است که دو همتا آن زیرشبکه را بپذیرند و مسیر بازگشت دوردستی به آن وجود داشته باشد، که معمولاً یعنی تغییر انتخابگر در دو سر و گفتوگو با مالک سمت دور. طراحی ترجمهشدهٔ عمدی در عوض باید نشانیای پوششداده با سیاست را در مرحلهٔ جستوجوی مربوط ارائه کند، که معمولاً یعنی قاعدهای تنگ و مستند به جای MASQUERADE پیشفرض.
هیچیک از این دو چیدمان بهطور خودکار از تونل کارکنندهٔ میزبان برنمیآید، و گزینش میان آنها تصمیمی طراحی با مالک است. بنویسید کدام را برگزیدید، وگرنه مهندس بعدی آن را دوباره از شمارندههای دیوار آتش بیرون میکشد.
مراقب خرابی ترکیبی هم باشید: نیمی از مجموعهٔ قواعد ترجمهشده و نیمی نه، که موفقیتی متناوب پدید میآورد وابسته به درگاه مقصد و نه چیزی در شبکه.
با اتصالی تازه بررسی کنید نه با راهاندازی دوباره
از اتصال تازهٔ برنامه استفاده کنید و در همان حال شمارندههای تنگ دیوار آتش و گیرندهٔ دور را بپایید، تا هر مشاهده منبعی داشته باشد. راهاندازی دوبارهٔ Docker میتواند وضعیت قواعد را تغییر دهد و بارهای کاری را هم مختل میکند و این سیگنال پاک را که میخواستید از شما میگیرد.
نتیجهٔ پایدار چهار گزاره است که میتوانید نشان دهید: منبع کانتینر، مسیر محافظتشدهٔ همخوان، ارسال جلوی مجاز، و پاسخی که بازمیگردد. وقتی هر چهار برجاست، کانتینر به همان دلیلی به همتا میرسد که میزبان میرسد.