☰

вступление

tag-icon • tag-icon debian vpn dns java firewall
вступление

вступление

У меня есть микросервис, работающий внутри контейнера Docker и развернутый на виртуальной машине с ОС Debian 10. IP-адрес сервера — 141.45.146.55.

Микросервис предоставляет следующий API:

GET https://<host>:8636/?username=<username>&password=<password>

который выполняет запрос аутентификации LDAP на сервере LDAP на другом узле, скажем: ldaps://example.com:636. IP-адрес example.com — 141.45.11.192 (это вывод nslookup example.com на сервере).

Все работает нормально, если брандмауэр на сервере, на котором запущен микросервис, отключен, но если я включаю брандмауэр, то при выполнении HTTP-запроса на miroservice возникает следующее исключение:

javax.naming.CommunicationException: example.com:636 [Root exception is java.net.UnknownHostException: example.com]

Похоже, что брандмауэр блокирует соединение между микросервисом и удаленным сервером LDAP с хостом ldaps://example.com:636.

Вопрос

Какое правило брандмауэра мне нужно добавить (или удалить) в скрипт брандмауэра, чтобы это заработало? Для полноты картины я добавляю содержимое скриптов брандмауэра:

iptables -F
iptables -t nat -F

iptables -P INPUT DROP
iptables -P FORWARD ACCEPT
iptables -P OUTPUT ACCEPT

#
# Allow only 141.45.x.x
#
iptables -A INPUT -m state --state ESTABLISHED -j ACCEPT
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -s 141.45.0.0/16 -j ACCEPT
#
iptables -A INPUT -p tcp -m tcp --dport 8443 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A INPUT -p tcp -m tcp --dport 8636 -m state --state NEW,ESTABLISHED -j ACCEPT

iptables-save > /etc/firewall.conf
#
echo -n "#"      > /etc/network/if-up.d/iptables
echo -n !       >> /etc/network/if-up.d/iptables
echo /bin/sh    >> /etc/network/if-up.d/iptables
echo "iptables-restore < /etc/firewall.conf" >> /etc/network/if-up.d/iptables
#
chmod +x /etc/network/if-up.d/iptables
#

Я также хотел бы отметить, что mircoservice работает внутри контейнера Docker.Если я отключу брандмауэр и перезагружу виртуальную машину, все работает нормально, но когда я включаю брандмауэр, микросервис выдает исключение java.net.UnknownHostException.

root:~# iptables -L
Chain INPUT (policy DROP)
target     prot opt source               destination
ACCEPT     all  --  anywhere             anywhere             state ESTABLISHED
ACCEPT     all  --  anywhere             anywhere
ACCEPT     all  --  141.45.0.0/16        anywhere
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:8443 state NEW,ESTABLISHED
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:8636 state NEW,ESTABLISHED

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Chain DOCKER-USER (0 references)
target     prot opt source               destination

Chain DOCKER (0 references)
target     prot opt source               destination
ACCEPT     tcp  --  anywhere             172.18.0.2           tcp dpt:https
ACCEPT     tcp  --  anywhere             172.18.0.3           tcp dpt:postgresql
ACCEPT     tcp  --  anywhere             172.18.0.4           tcp dpt:https
ACCEPT     tcp  --  anywhere             172.18.0.5           tcp dpt:https

Chain DOCKER-ISOLATION-STAGE-1 (0 references)
target     prot opt source               destination

Chain DOCKER-ISOLATION-STAGE-2 (0 references)
target     prot opt source               destination

Что я уже сделал

Я прочитал Javadoc java.net.UnknownHostException, там говорится:

Вызывается, чтобы указать, что IP-адрес хоста не может быть определен.

Итак, идея была в том, что брандмауэр, возможно, блокирует DNS, поэтому я попробовал nslookup example.comна сервере, где запущены микросервис и брандмауэр. К сожалению, nslookup работает, когда брандмауэр включен. Он разрешает example.com.

Я также попробовал следующие правила:

iptables -I INPUT -p tcp --sport 636 -j ACCEPT
iptables -I INPUT -p udp --sport 636 -j ACCEPT
iptables -I INPUT -p tcp --dport 636 -j ACCEPT
iptables -I INPUT -p udp --dport 636 -j ACCEPT

Но безуспешно. Администратор сказал мне, что это не обязательно, поскольку мы находимся за брандмауэром (внутри одной сети), но поскольку я разработчик микросервиса, а администратор не знаком с Docker, то мне придется запустить микросервис с включенным брандмауэром.

Есть еще идеи? Боюсь, это как-то связано с Docker, что вы думаете?

docker ps
CONTAINER ID   IMAGE                                     COMMAND                  CREATED      STATUS        PORTS                          
c67630f9118b   dawidlokiec/ldap-authentication-service   "/opt/docker/bin/lda…"   2 days ago   Up 18 hours   0.0.0.0:8636->443/tcp
and three other contains ...

Почему существуют некоторые специфичные для Docker цепочки, а адреса назначения — 172.18.0.X, а не != 141.45.XX? В чем проблема?

Связанный контент