Тест проксі має провалювати пряме з’єднання
Відокремте тестову мережу застосунку від виходу проксі, щоб непомічене пряме з’єднання не робило тест проксі успішним.
Локальний проксі, що слухає поруч із застосунком, не відтворює мережу, яка вимагає доступу через проксі. Застосунок може проігнорувати налаштований проксі, підключитися напряму і все одно повідомити про успіх.
Відокремте мережу застосунку від зовнішнього шляху проксі. Одна схема на контейнерах розміщує застосунок лише у внутрішній мережі, а проксі отримує другу вихідну мережу. У наявному визначенні Compose підключення до мереж можуть виглядати так:
services:
app:
networks: [clients]
proxy:
networks: [clients, egress]
networks:
clients:
internal: true
egress: {}
Це фрагмент мережі для вже визначених сервісів. Налаштуйте схвалений пересильний проксі та фактичний клієнт застосунку окремо. Docker описує внутрішні мережі як ізольовані ззовні; у цій схемі додаткову зовнішню мережу має лише проксі.
Додайте негативний випадок без використання проксі: зовнішній запит застосунку має завершитися невдачею. Для HTTP-проксі з автентифікацією відхилений обліковий запис має давати власну помилку автентифікації, а прийнятий — досягати цілі з відповідним спостереженням з боку проксі.
Перевіряйте дозволені та заборонені випадки проксі окремо. Тримайте застосунок поза іншими зовнішніми мережами й не додавайте режим мережі хоста, що обходить проксі. Успішний запит є корисним доказом лише тоді, коли тест надає саме задуманий маршрут.