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 або правила клієнта мережі, щоб «скинути» доступ. Обидва продукти встановлюють свою інтеграцію політик, і її видалення дає хост, який виглядає працюючим, але обходить ті засоби контролю, які вас просили оцінити. Якщо правило виглядає неправильним, прочитайте його й змініть саме це правило. Якщо ви не можете пояснити, що робить правило, це і є знахідка, а не причина його видаляти.

Напишіть знахідку термінами самої системи

Важлива та відмінність, яку продукт справді забезпечує, а не та, що в шаблоні розгляду: дозвіл досягти кінцевої точки хоста, дозвіл досягти маршрутизованих приватних ресурсів і дозвіл користуватися застосунком. Публікація порту залишає ці три рішення рівно там, де вони були, і той, хто вважає їх одним, схвалить неправильний обсяг.

Укажіть адресу хоста, опублікований порт, призначення контейнера й дозвіл вузла в одному реченні. Це речення може перевірити хтось інший, і саме це робить його знахідкою, а не думкою.