Локальний проксі, що слухає поруч із застосунком, не відтворює мережу, яка вимагає доступу через проксі. Застосунок може проігнорувати налаштований проксі, підключитися напряму і все одно повідомити про успіх.

Відокремте мережу застосунку від зовнішнього шляху проксі. Одна схема на контейнерах розміщує застосунок лише у внутрішній мережі, а проксі отримує другу вихідну мережу. У наявному визначенні Compose підключення до мереж можуть виглядати так:

services:
  app:
    networks: [clients]
  proxy:
    networks: [clients, egress]
networks:
  clients:
    internal: true
  egress: {}

Це фрагмент мережі для вже визначених сервісів. Налаштуйте схвалений пересильний проксі та фактичний клієнт застосунку окремо. Docker описує внутрішні мережі як ізольовані ззовні; у цій схемі додаткову зовнішню мережу має лише проксі.

Додайте негативний випадок без використання проксі: зовнішній запит застосунку має завершитися невдачею. Для HTTP-проксі з автентифікацією відхилений обліковий запис має давати власну помилку автентифікації, а прийнятий — досягати цілі з відповідним спостереженням з боку проксі.

Перевіряйте дозволені та заборонені випадки проксі окремо. Тримайте застосунок поза іншими зовнішніми мережами й не додавайте режим мережі хоста, що обходить проксі. Успішний запит є корисним доказом лише тоді, коли тест надає саме задуманий маршрут.

Схожі статті