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