Meshnet، Docker و مجوز میان آن‌ها

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

مجوز درباره نقطه پایانی میزبان است، ترجمه درباره Docker است و ورود درباره برنامه است. سه تصمیم، سه جای نگاه کردن.

مقصد را پس از انتشار دنبال کنید

یک میزبان Linux با Docker را در نظر بگیرید که پورت 80 یک کانتینر را روی پورت 8080 میزبان منتشر می‌کند. یک همتا به نشانی شبکه میزبان روی 8080 متصل می‌شود، میزبان اتصال را می‌پذیرد و یک ترجمه مقصد آن را به نشانی پل کانتینر بازنویسی می‌کند، معمولاً چیزی مانند 172.17.0.2 روی پورت 80.

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

به همین دلیل مستندات شبکه کانتینرهای Docker را در شمار منابعی می‌آورد که مجوز شبکه محلی در Linux بر آن‌ها حاکم است. مجوز مترادف یک ورودی معمولی در فهرست مجاز VPN نیست و این دو کنترل جای یکدیگر را نمی‌گیرند. یکی تصمیم می‌گیرد که آیا همتا اصلاً می‌تواند به منابع محلی برسد؛ دیگری تصمیم می‌گیرد که یک مسیر تونل‌شده کدام مقصدها را حمل می‌کند.

تصمیم بگیرید یک مجوز چه مقدار دسترسی محلی می‌دهد

دادن دسترسی شبکه محلی به یک همتا تصمیمی درباره یک کانتینر نیست. می‌تواند سرویس‌های منتشرشده دیگر روی همان میزبان را آشکار کند و بسته به نحوه ارسال میزبان ممکن است دورتر برسد. پیش از کلیک روی کلید یک داشبورد، دامنه مؤثر را بررسی کنید.

سپس ببینید Docker پورت را کجا منتشر می‌کند. انتشار روی 0.0.0.0 یک شنونده روی هر نشانی میزبان ایجاد می‌کند که می‌تواند یک ورودی معمولی LAN را در کنار ورودی شبکه اضافه کند. اگر نیاز فقط شبکه است، انتشار را به نشانی یا رابط مشخصی که در نظر دارید مقید کنید و مقیدسازی گسترده‌تر را یافته‌ای جداگانه بدانید، نه یک راحتی.

سیاست ارسال میزبان و احراز هویت خود برنامه را به اندازه کافی برای سرویس محدود نگه دارید. URLی که خصوصی به نظر می‌رسد کنترل دسترسی نیست و کانتینری که به هر منبعی در شبکه پل خود اعتماد می‌کند با تأیید همتای شبکه محافظت نمی‌شود. احراز هویت برنامه سومین تصمیم است و تنها تصمیمی است که می‌داند کاربر کیست. یک مجوز در سطح میزبان نمی‌تواند این دانش را فراهم کند.

مجوز را آزمایش کنید، نه فقط URL را

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

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

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

یافته را با اصطلاحات خود سیستم بنویسید

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

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