Когда разбирался с контейнером openvpn-monitor, про который вчера писал, пришлось немного его подебажить, так как он никак не хотел подключаться к консоли OpenVPN сервера. Писал стандартную ошибку в веб интерфейсе - connection timeout и адрес с портом сервера. Я и так, и сяк адреса и доменные имена пробовал, ни в какую.

Как это обычно бывает, контейнер внутри пустой. Там нет ничего, что помогло бы проверить сетевую связность. Ситуация рядовая, так что решение в целом понятное. У меня было несколько заметок по этой теме. Расскажу, как я решал задачу.

Есть удобный инструмент cdebug. Представляет из себя обычный бинарник. Скачиваем его на хост, где работает контейнер:

# mkdir ~/cdebug && cd ~/cdebug
# wget https://github.com/iximiuz/cdebug/releases/download/v0.0.18/cdebug_linux_amd64.tar.gz
# tar xzvf cdebug_linux_amd64.tar.gz

Подключаемся к нашему контейнеру:

# ./cdebug exec -it openvpn-monitor

Оказываемся в его консоли и получаем все утилиты из комплекта BusyBox. Там мне понадобились буквально 2 утилиты: ping и telnet. Сначала пинганул VPN сервер и убедился, что сетевая связность есть. Потом через telnet понял, что не подключаюсь к настроенному порту консоли.

Оказалось, что банально файрвол блокировал запросы. В принципе, я об этом догадывался, но там много правил было наворочено. Думал, что доступ будет. Не хотелось лишний раз трогать iptables и включать логирование всех заблокированных пакетов. Там бы я тоже увидел, что соединения блокируются. Вариант с cdebug показался проще. Убедился наверняка, что проблема с файрволом и поменял некоторые правила.

С помощью cdebug можно подключаться к подам кубера. В докере можно пробрасывать новые порты из контейнера на хост без перезапуска контейнера. Можно подцепить к контейнеру образ с tshark на борту и собрать трафик изнутри контейнера. Очень простая и удобная программа. Если работаете с контейнерами, рекомендую сохранить и освоить.

❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.

#docker #devops