Я пытаюсь направить весь трафик док-контейнера через mitmproxy, работающий в другом док-контейнере. Чтобы mitmproxy работал, мне нужно изменить IP-адрес шлюза исходного контейнера докеров.
Вот пример того, что я хочу сделать, но я хочу, чтобы это было полностью внутри docker контейнеров.
Любые мысли о том, как я мог бы быть в состоянии сделать это? Кроме того, я хочу избежать запуска любого из двух контейнеров докеров в привилегированном режиме.
Набор возможностей по умолчанию, предоставленный контейнерам, не позволяет контейнеру изменять сетевые настройки. Запуская в привилегированном режиме, вы предоставляете контейнеру все возможности, но есть также возможность предоставлять отдельные возможности по мере необходимости. В этом случае тот, который вам нужен, называется CAP_NET_ADMIN (полный список здесь: http://man7.org/linux/man-pages/man7/capabilities.7.html), поэтому вы можете добавить --cap-add NET_ADMIN к команде запуска докера.
Обязательно используйте эту опцию при запуске обоих контейнеров, так как они оба требуют некоторых настроек сети, чтобы включить прозрачный перехват пакетов.
В контейнере «прокси» настройте правило NAT предварительной маршрутизации iptables в соответствии с инструкциями mitmproxy прозрачного режима, затем запустите mitmproxy (с флагом -T для включения прозрачного режима). Я использую небольшой стартовый скрипт в качестве точки входа прокси-образа для этого, поскольку изменения сетевых настроек происходят только во время выполнения контейнера и не могут быть указаны в Dockerfile или сохранены иным образом.
В «клиентском» контейнере просто используйте команды ip route, чтобы изменить шлюз по умолчанию на IP-адрес прокси-контейнера на мосту докера. Если вы будете регулярно повторять эту настройку, рассмотрите возможность использования сценария точки входа в клиентском образе, который настроит ее автоматически при запуске контейнера. Связывание контейнеров упрощает эту задачу: вы можете запустить прокси-контейнер и связать его при запуске клиентского контейнера. Затем сценарий точки входа клиента получает доступ к IP-адресу прокси-контейнера через переменную среды.
Кстати, если вы можете обойтись без использования mitmproxy в непрозрачном режиме (явно настройте клиент для использования HTTP-прокси), я настоятельно рекомендую его. Гораздо меньше головной боли при настройке.
Удачи повеселиться!
