[uanog] AWS private VPC, NAT gateway, ACL... нема доступу в outside world from docker container of docker host.
Volodymyr Sharun
atz at ukr.net
Sun Jan 8 14:07:42 EET 2023
Привіт,
Я б попершу подивився, чи є егресс пакет від докеру на зовнішньому
інтерфейсі вже "заначений", і, що суттєво - який src ip. Тобто ти робиш
apt update, і ця активність повинна виходити із зовнішнього інтерфейса
хоста. Якщо її там немає, то скоріше за все є богус фільтр на хості.
Пакет з зовнішнього адаптера повинен вийти.
Ну а далі питання - він виходить з ip хоста, чи з ip контейнера. У
першому випадку - до VPC gateway йдемо або до полісі у VPC, у другому
(ip контейнера) - треба робити NAT.
Не бажаєш tcp proxy поставити на хост ? Відправляти через нього. Тоді і
NAT не треба буде робити на хості, логгінг активності, усе таке. Секюрна
тема :)
On 08/01/23 13:18, Oleh Hrynchuk wrote:
> Дякую, колеги.
>
> Проблема дійсно десь на подальших хопах від docker host.
>
> tcpdump показує, що запити від контейнера (результат запущеної там
> команди *apt update*) покидають зовнішній інтерфейс eth0 docker-хоста.
> І десь губляться далі (відповіді вже не приходять).
> Буду далі колупатися.
>
> Причому приватна AWS VPC має адреси 10.х.х.х/24, а docker network
> 172.17.0.0/16 <http://172.17.0.0/16>. Тому mismatching ІР-адрес там не
> відбувається.
> NACL ніби нормально там... ось NAT gateway ще не дивився...
>
>
>
>
>
> нд, 8 січ. 2023 р. о 12:29 VASYL MELNYK <basil at vpm.net.ua> пише:
>
> привіт
>
> Л2 можна перевірити з хост-системи, просто подивитись таблицю арп
> та й пінги в сторону контейнера повинні йти. Якщо пінги ходять в
> контейнер, тоді можна встановити на хост-машині проксі-сервер і
> вже через нього встановити в контейнер софт для діагностики.
>
>
> нд, 8 січ. 2023 р. о 08:43 Oleh Hrynchuk <oleh.hrynchuk at gmail.com>
> пише:
>
> Доброго дня всім,
>
> Шановне панство, маю питання стосовно security policy в
> private VPC of AWS.
>
> Суть в наступному.
>
> Нам "старші товариші з US" приписали завести одну docker-type
> аплікуху в спеціально виділеній private VPC на спеціальному ЕС2.
> "Спеціальність" останнього полягає в попередній "заточці"
> стандартного Amazon Linux 2 AMI під корпоративні правила
> безпеки. Зокрема вмиканні там SeLinux, сетапі спеціальних
> nftables.rules тощо.
>
> І вийшло так, що ніби все з матюками вдалося зробити (SELinux
> довелося вирубати "за згодою сторін") за винятком одного:
> email notifications (на порт 587 GMail SMTP) принципово з
> контейнера не ходять. А ось із docker host (отого ЕС2) -
> нормально ходять.
> Також неможливо з докер-контейнера (там Ubuntu) виконати
> оновлення OS (apt update) - нема доступу назовні.
>
> Враження наступне - з контейнера НЕМА доступу до Інтернета. З
> docker-хоста - є.
> Ще така фігня, що в контейнері нема найнеобхідніших
> інструментів для траблшутинга - навіть ping/traceroute. І не
> поставиш - apt не має виходу назовні.
> (Ну, тут можна із"їбнутися і підсунути щось в docker volume
> напряму... ще ось не пробував так, але спробую).
>
> Підозра падає на NAT Gateway між private VPC та outside world.
>
> Чи хтось з таким стикався і що робити, щоби це а) точно
> локалізувати; б) полікувати цю фігню.
> Може це якась стандартна фігня, а я не знаю про це?
>
> Дякую.
>
> --
> Regards,
> /oleh hrynchuk
> _______________________________________________
> uanog mailing list
> uanog at uanog.kiev.ua
> https://mailman.uanog.kiev.ua/mailman/listinfo/uanog
>
>
>
> --
> Regards,
> /oleh hrynchuk
>
> _______________________________________________
> uanog mailing list
> uanog at uanog.kiev.ua
> https://mailman.uanog.kiev.ua/mailman/listinfo/uanog
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.uanog.kiev.ua/pipermail/uanog/attachments/20230108/d754e087/attachment.htm>
More information about the uanog
mailing list