The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



"Двойной проброс порта во внутреннюю сеть"
Вариант для распечатки  
Пред. тема | След. тема 
Форум Информационная безопасность (Linux iptables, ipchains)
Изначальное сообщение [ Отслеживать ]

"Двойной проброс порта во внутреннюю сеть"  +1 +/
Сообщение от KSSh (ok), 09-Июн-20, 16:18 
Всем привет!
Помогите, пожалуйста, сделать настройки. Второй день бьюсь - не пойму, как правильно надо. Сам я программер, в администрировании слаб.
Нужно реализовать такую схему:
https://i.imgur.com/jItnjDz.png
Т.е. пробросить порт внутрь сети дважды.
При этом доступ есть только к IIS_SRV_WIN и LINSRV.
Как должно быть:
1) Пользователь из интернет стучится на GATEWAY:8888
2) Трафик пробрасывается на LINSRV:8888 как есть (это настроено админами, работает)
3) LINSRV посредством iptables пробрасывает трафик на IIS_SRV_WIN:443.
4) IIS_SRV_WIN отвечает на LINSRV
5) LINSRV отдает счастливому пользователю его веб-страничку через GATEWAY.

Не спрашивайте, почему не напрямую с GATEWAY на IIS_SRV_WIN - можно только так, планируется развитие этого всего с модификацией трафика на LINSRV, но это в будущем.

Сейчас вопрос в том, что почему-то не работает :(
Настроил на LINSRV такие правила:
iptables -t nat -I PREROUTING 1 -p tcp -d LINSRV --dport 8888 -j DNAT --to-destination IIS_SRV_WIN:443
iptables -I FORWARD 1 -d IIS_SRV_WIN -p tcp --dport 443 -j ACCEPT
Так же пробовал добавлять такое:
iptables -t nat -A POSTROUTING -j MASQUERADE
В результате - не работает. При этом, проверил следующее:
В лог IIS падает запись о подключении, когда я стучусь через интернет на GATEWAY:8888. Т.е. в этом направлении пакеты проходят. А вот обратно - уже не доходят. Судя по всему, теряются на LINSRV или после него.
При этом у стучащегося пользователя браузер висит минуту и говорит ERR_CONNECTION_TIMEOUT.

Подскажите, каких правил не хватает, или что нужно проверить, чтобы найти проблему?

Дополнительно делал следующее:
- Убирал правила firewall и поднимал apache на linsrv:8888 - тестовый сайт-заглушка из интернет виделся корректно.
- через wget на linsrv получал сайт с IIS_SRV_WIN. Точнее, получал ошибку, что такого сайта нет (т.к. стучал по IP, а сайт работает на доменном имени), но хоть что-то получал.

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения [Сортировка по времени | RSS]


1. "Двойной проброс порта во внутреннюю сеть"  +3 +/
Сообщение от ACCA (ok), 09-Июн-20, 19:46 
Через iptables и routing это можно сделать, но не нужно.

Есть нюанс - в результате у тебя IIS выставлен голой жопой в интернет, что плохо закончится и для IIS и для Internet.

Что следует сделать - SSL на IIS выключить, пусть отдаёт HTTP. На LINSRV запустить тот же HAPROXY или NGINX, сделать reverse proxy c SSL на нём.

Ответить | Правка | Наверх | Cообщить модератору

3. "Двойной проброс порта во внутреннюю сеть"  +/
Сообщение от KSSh (ok), 09-Июн-20, 20:18 
> Через iptables и routing это можно сделать, но не нужно.
> Есть нюанс - в результате у тебя IIS выставлен голой жопой в
> интернет, что плохо закончится и для IIS и для Internet.
> Что следует сделать - SSL на IIS выключить, пусть отдаёт HTTP. На
> LINSRV запустить тот же HAPROXY или NGINX, сделать reverse proxy c
> SSL на нём.

Там на интерфейсе GATEWAY есть жесткое правило - доступ только из строго ограниченного пула IP, так что завалить не выйдет. Да и не прод это, а среда разработки будущая.
Поэтому, меньшей кровью было бы настроить одно-два правила iptables.

Если не получится так - то придется, наверное, haproxy или nginx. Но для меня, как не для админа, это будут дополнительные сложности. Хотел как поскорее) А какой из этих двух вариантов проще заведется?

Ответить | Правка | Наверх | Cообщить модератору

2. "Двойной проброс порта во внутреннюю сеть"  +/
Сообщение от Licha Morada (ok), 09-Июн-20, 20:12 

Вам правильно посоветовали, не надо публиковать вебсервисы пробросом портов. Прокси справляется с этой задачей лучше.

Если же всё-таки очень надо, то обсуждали недавно:
https://www.opennet.dev/openforum/vsluhforumID10/5518.html
https://www.opennet.dev/openforum/vsluhforumID10/5529.html

Вкратце, понадобится:
Чтоб был packet forwarding.
Чтоб netfilter разрешил пакетам ходить.
Правило DNAT чтоб скрыть IIS_SRV_WIN от GATEWAY.
Правило SNAT чтоб скрыть GATEWAY от IIS_SRV_WIN.
MASQUERADE не нужен.

Но лучше через прокси.

Ответить | Правка | Наверх | Cообщить модератору

4. "Двойной проброс порта во внутреннюю сеть"  +/
Сообщение от KSSh (ok), 09-Июн-20, 20:27 
>[оверквотинг удален]
> Если же всё-таки очень надо, то обсуждали недавно:
> https://www.opennet.dev/openforum/vsluhforumID10/5518.html
> https://www.opennet.dev/openforum/vsluhforumID10/5529.html
> Вкратце, понадобится:
> Чтоб был packet forwarding.
> Чтоб netfilter разрешил пакетам ходить.
> Правило DNAT чтоб скрыть IIS_SRV_WIN от GATEWAY.
> Правило SNAT чтоб скрыть GATEWAY от IIS_SRV_WIN.
> MASQUERADE не нужен.
> Но лучше через прокси.

Спасибо огромное! Завтра будет возможность попробовать применить, думаю поможет. Интуитивно понимал, что что-то похожее нужно, но не знал как.)
А по поводу безопасности - отписался в предыдущем комментарии)

Ответить | Правка | Наверх | Cообщить модератору

5. "Двойной проброс порта во внутреннюю сеть"  +/
Сообщение от Licha Morada (ok), 10-Июн-20, 01:01 

> Там на интерфейсе GATEWAY есть жесткое правило - доступ только из строго
> ограниченного пула IP, так что завалить не выйдет.

Хорошо, но мало. Эшелонирование защиты это дешёвая и эффективная мера. Зачем ей пренебрегать?
У вас правильная топология на картинке нарисована. Пусть GATEWAY следит чтоб не лезли откуда попало, а LINSRV (если туда поставить прокси который умеет HTTP) следит чтоб совсем дичь не творили.

> Да и не прод это, а среда разработки будущая.

Во-во. Не прод это такое вкусное место, где бывают пароли test:test, права файлов 777 "потом пофиксим", временно закороченные валидации, недоросший до ревью джунский код... Кисельные берега.

> Если не получится так - то придется, наверное, haproxy или nginx. Но
> для меня, как не для админа, это будут дополнительные сложности.

Не более чем iptables, где в логику packet traversal вникать надо и за персистентностью следить.
Почитайте туториалы про обоих, попробуйте так и сяк. Считайте что их конфиги это такой декларативный язык программирования.

Ответить | Правка | Наверх | Cообщить модератору

6. "Двойной проброс порта во внутреннюю сеть"  +/
Сообщение от KSSh (ok), 10-Июн-20, 02:01 
> Хорошо, но мало. Эшелонирование защиты это дешёвая и эффективная мера. Зачем ей
> пренебрегать?
> У вас правильная топология на картинке нарисована. Пусть GATEWAY следит чтоб не
> лезли откуда попало, а LINSRV (если туда поставить прокси который умеет
> HTTP) следит чтоб совсем дичь не творили.

Честно говоря, мне не понятно, чем прокси в данном случае был бы лучше, чем проброс портов.
На внешний интерфейс GATEWAY разрешено стучаться трем ip. По сути, это просто торчащее наружу API для трех удаленных адресов.
А на ближайшее будущее - планируется перенос приложения с сервака iis на linsrv в виде пачки docker-контейнеров. Постепенно, понемножку, чтобы в общем приложение всегда было рабочим. А потом и полностью отказаться от iis, а следовательно, и от проброса портов на него

Ответить | Правка | Наверх | Cообщить модератору

7. "Двойной проброс порта во внутреннюю сеть"  +/
Сообщение от Licha Morada (ok), 10-Июн-20, 22:55 

> Честно говоря, мне не понятно, чем прокси в данном случае был бы
> лучше, чем проброс портов.
> На внешний интерфейс GATEWAY разрешено стучаться трем ip. По сути, это просто
> торчащее наружу API для трех удаленных адресов.

Причин много разных. В каких-то случаях будут более существенны одни из них, в каких-то - другие.
Например:
- Обратный прокси сервер ведёт компактные и удобочитаемые логи. Можно меньше прибегать к снифферу при поиске источника проблем.
- До настоящего веб приложения долетают только заведомо корректные HTTP запросы, а не какой попало мусор который послали в открытый порт. Дешовая защита от атак, эксплуатирующих особенности сетевого уровня, типа Slowloris.
- Легко публиковать не весь корень веб сервера апстрима, где может быть админка или другие приложения, а только избранные пути.
- Централизованное терминирование сессий TLS позволяет снизить риск ошибок конфигурации.
- Легко контролировать текущую конфигурацию "что куда и как пробрасывается" и делегировать поддержку.
- Удобно стандартизировать. Одно и то-же решение покрывает множество кейсов, от простого "опубликовать в интернете" до баланисровки нагрузки и кэширования статичного контента.
- Решение находится на одном и том-же уровне абстракции (веб сервис) что и задача (опубликовать в Интернете).
- И т.д.

> А на ближайшее будущее - планируется перенос приложения с сервака iis на
> linsrv в виде пачки docker-контейнеров. Постепенно, понемножку, чтобы в общем приложение
> всегда было рабочим. А потом и полностью отказаться от iis, а
> следовательно, и от проброса портов на него

Хороший план. Докерские best practices всё равно рекомендуют reverse proxy. Имеет смысл с него и начать, используя IIS в качестве апстрима для всех сервисов, и постепенно переводя их куда надо.


Ответить | Правка | Наверх | Cообщить модератору

8. "Двойной проброс порта во внутреннюю сеть"  +/
Сообщение от KSSh (ok), 12-Июн-20, 10:08 
Поднял реверс прокси на nginx, спасибо!
Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру