Telegram Group & Telegram Channel
🌐 Задача-ловушка: Пропавший трафик после настройки iptables

Условие:

На сервере настроен простой iptables-фильтр для блокировки всего входящего трафика, кроме SSH:


iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT
iptables -A INPUT -p tcp --dport 22 -j ACCEPT


После применения этих правил вы проверяете, что SSH соединения работают нормально (локально и удалённо). Сервер отвечает на пинги, всё ок.

На следующий день вы добавляете локальный контейнер (например, Docker), запускаете его с пробросом порта:


docker run -d -p 8080:80 nginx


Проблема: Снаружи контейнер не доступен. В браузере или curl получаете Connection refused. Но в ss -tlnp порт 8080 виден и слушает.

Дополнительно, если выполнить:


curl http://localhost:8080


— сервер отвечает нормально. Но с других машин — нет.

Вопрос:
Почему порт 8080 недоступен извне? В чём подвох с iptables? Как починить проблему?

🔍 Подсказка:

Docker использует nat таблицы и PREROUTING`/`FORWARD цепочки для проброса портов.


Разбор:

💥 Ловушка:

Ваш iptables-правила:


iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -A INPUT -p tcp --dport 22 -j ACCEPT


запрещают ВСЁ, кроме SSH. Вы думаете, что входящие соединения через Docker должны идти через INPUT, но это не так!

Когда Docker пробрасывает порт с хоста (например, 8080), схема такая:

- Входящий пакет попадает в цепочку PREROUTING (nat)
- Потом через FORWARD, если пакет не адресован хосту напрямую, а перенаправлен внутрь контейнера

И тут главная ловушка: даже если контейнер слушает порт на 0.0.0.0, Docker обрабатывает проброс трафика через FORWARD, а у вас политика по умолчанию:


iptables -P FORWARD DROP


Поэтому трафик до контейнера блокируется именно на этапе FORWARD.

🔧 Как проверить:

Запустить:


iptables -L -v -n


Вы увидите, что счётчик пакетов в FORWARD показывает дропы.

🛠 Как починить:

Добавить правило разрешения проброса пакетов для Docker:


iptables -A FORWARD -o docker0 -j ACCEPT


Или (более строго):


iptables -A FORWARD -i eth0 -o docker0 -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A FORWARD -i docker0 -o eth0 -j ACCEPT


Вывод:

• В Linux iptables цепочки работают по строгой логике:
- INPUT — для пакетов к хосту
- FORWARD — для пакетов, которые переходят через хост (например, контейнеры или маршрутизаторы)

• Даже если кажется, что контейнер слушает на 0.0.0.0, проброс портов Docker работает через FORWARD, а не напрямую через INPUT.

💡 Бонус-вопрос:
Что изменится, если вы запустите контейнер с флагом --network=host? Какие цепочки будут задействованы тогда?



tg-me.com/DevOPSitsec/1495
Create:
Last Update:

🌐 Задача-ловушка: Пропавший трафик после настройки iptables

Условие:

На сервере настроен простой iptables-фильтр для блокировки всего входящего трафика, кроме SSH:


iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT
iptables -A INPUT -p tcp --dport 22 -j ACCEPT


После применения этих правил вы проверяете, что SSH соединения работают нормально (локально и удалённо). Сервер отвечает на пинги, всё ок.

На следующий день вы добавляете локальный контейнер (например, Docker), запускаете его с пробросом порта:


docker run -d -p 8080:80 nginx


Проблема: Снаружи контейнер не доступен. В браузере или curl получаете Connection refused. Но в ss -tlnp порт 8080 виден и слушает.

Дополнительно, если выполнить:


curl http://localhost:8080


— сервер отвечает нормально. Но с других машин — нет.

Вопрос:
Почему порт 8080 недоступен извне? В чём подвох с iptables? Как починить проблему?

🔍 Подсказка:

Docker использует nat таблицы и PREROUTING`/`FORWARD цепочки для проброса портов.


Разбор:

💥 Ловушка:

Ваш iptables-правила:


iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -A INPUT -p tcp --dport 22 -j ACCEPT


запрещают ВСЁ, кроме SSH. Вы думаете, что входящие соединения через Docker должны идти через INPUT, но это не так!

Когда Docker пробрасывает порт с хоста (например, 8080), схема такая:

- Входящий пакет попадает в цепочку PREROUTING (nat)
- Потом через FORWARD, если пакет не адресован хосту напрямую, а перенаправлен внутрь контейнера

И тут главная ловушка: даже если контейнер слушает порт на 0.0.0.0, Docker обрабатывает проброс трафика через FORWARD, а у вас политика по умолчанию:


iptables -P FORWARD DROP


Поэтому трафик до контейнера блокируется именно на этапе FORWARD.

🔧 Как проверить:

Запустить:


iptables -L -v -n


Вы увидите, что счётчик пакетов в FORWARD показывает дропы.

🛠 Как починить:

Добавить правило разрешения проброса пакетов для Docker:


iptables -A FORWARD -o docker0 -j ACCEPT


Или (более строго):


iptables -A FORWARD -i eth0 -o docker0 -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A FORWARD -i docker0 -o eth0 -j ACCEPT


Вывод:

• В Linux iptables цепочки работают по строгой логике:
- INPUT — для пакетов к хосту
- FORWARD — для пакетов, которые переходят через хост (например, контейнеры или маршрутизаторы)

• Даже если кажется, что контейнер слушает на 0.0.0.0, проброс портов Docker работает через FORWARD, а не напрямую через INPUT.

💡 Бонус-вопрос:
Что изменится, если вы запустите контейнер с флагом --network=host? Какие цепочки будут задействованы тогда?

BY DevOps


Warning: Undefined variable $i in /var/www/tg-me/post.php on line 283

Share with your friend now:
tg-me.com/DevOPSitsec/1495

View MORE
Open in Telegram


DevOps Telegram | DID YOU KNOW?

Date: |

The STAR Market, as is implied by the name, is heavily geared toward smaller innovative tech companies, in particular those engaged in strategically important fields, such as biopharmaceuticals, 5G technology, semiconductors, and new energy. The STAR Market currently has 340 listed securities. The STAR Market is seen as important for China’s high-tech and emerging industries, providing a space for smaller companies to raise capital in China. This is especially significant for technology companies that may be viewed with suspicion on overseas stock exchanges.

Unlimited members in Telegram group now

Telegram has made it easier for its users to communicate, as it has introduced a feature that allows more than 200,000 users in a group chat. However, if the users in a group chat move past 200,000, it changes into "Broadcast Group", but the feature comes with a restriction. Groups with close to 200k members can be converted to a Broadcast Group that allows unlimited members. Only admins can post in Broadcast Groups, but everyone can read along and participate in group Voice Chats," Telegram added.

DevOps from us


Telegram DevOps
FROM USA