 Двойной проброс порта во внутреннюю сеть,  KSSh, 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, а сайт работает на доменном имени), но хоть что-то получал.
|
- Двойной проброс порта во внутреннюю сеть, ACCA, 19:46 , 09-Июн-20 (1) +3
Через iptables и routing это можно сделать, но не нужно.Есть нюанс - в результате у тебя IIS выставлен голой жопой в интернет, что плохо закончится и для IIS и для Internet. Что следует сделать - SSL на IIS выключить, пусть отдаёт HTTP. На LINSRV запустить тот же HAPROXY или NGINX, сделать reverse proxy c SSL на нём.
- Двойной проброс порта во внутреннюю сеть, KSSh, 20:18 , 09-Июн-20 (3)
> Через iptables и routing это можно сделать, но не нужно.
> Есть нюанс - в результате у тебя IIS выставлен голой жопой в
> интернет, что плохо закончится и для IIS и для Internet.
> Что следует сделать - SSL на IIS выключить, пусть отдаёт HTTP. На
> LINSRV запустить тот же HAPROXY или NGINX, сделать reverse proxy c
> SSL на нём.Там на интерфейсе GATEWAY есть жесткое правило - доступ только из строго ограниченного пула IP, так что завалить не выйдет. Да и не прод это, а среда разработки будущая.
Поэтому, меньшей кровью было бы настроить одно-два правила iptables. Если не получится так - то придется, наверное, haproxy или nginx. Но для меня, как не для админа, это будут дополнительные сложности. Хотел как поскорее) А какой из этих двух вариантов проще заведется?
- Двойной проброс порта во внутреннюю сеть, Licha Morada, 20:12 , 09-Июн-20 (2)
- Двойной проброс порта во внутреннюю сеть, KSSh, 20:27 , 09-Июн-20 (4)
>[оверквотинг удален]
> Если же всё-таки очень надо, то обсуждали недавно:
> https://www.opennet.me/openforum/vsluhforumID10/5518.html
> https://www.opennet.me/openforum/vsluhforumID10/5529.html
> Вкратце, понадобится:
> Чтоб был packet forwarding.
> Чтоб netfilter разрешил пакетам ходить.
> Правило DNAT чтоб скрыть IIS_SRV_WIN от GATEWAY.
> Правило SNAT чтоб скрыть GATEWAY от IIS_SRV_WIN.
> MASQUERADE не нужен.
> Но лучше через прокси.Спасибо огромное! Завтра будет возможность попробовать применить, думаю поможет. Интуитивно понимал, что что-то похожее нужно, но не знал как.)
А по поводу безопасности - отписался в предыдущем комментарии)
- Двойной проброс порта во внутреннюю сеть, Licha Morada, 01:01 , 10-Июн-20 (5)
> Там на интерфейсе GATEWAY есть жесткое правило - доступ только из строго
> ограниченного пула IP, так что завалить не выйдет.Хорошо, но мало. Эшелонирование защиты это дешёвая и эффективная мера. Зачем ей пренебрегать?
У вас правильная топология на картинке нарисована. Пусть GATEWAY следит чтоб не лезли откуда попало, а LINSRV (если туда поставить прокси который умеет HTTP) следит чтоб совсем дичь не творили. > Да и не прод это, а среда разработки будущая. Во-во. Не прод это такое вкусное место, где бывают пароли test:test, права файлов 777 "потом пофиксим", временно закороченные валидации, недоросший до ревью джунский код... Кисельные берега. > Если не получится так - то придется, наверное, haproxy или nginx. Но
> для меня, как не для админа, это будут дополнительные сложности. Не более чем iptables, где в логику packet traversal вникать надо и за персистентностью следить.
Почитайте туториалы про обоих, попробуйте так и сяк. Считайте что их конфиги это такой декларативный язык программирования.
- Двойной проброс порта во внутреннюю сеть, KSSh, 02:01 , 10-Июн-20 (6)
> Хорошо, но мало. Эшелонирование защиты это дешёвая и эффективная мера. Зачем ей
> пренебрегать?
> У вас правильная топология на картинке нарисована. Пусть GATEWAY следит чтоб не
> лезли откуда попало, а LINSRV (если туда поставить прокси который умеет
> HTTP) следит чтоб совсем дичь не творили.Честно говоря, мне не понятно, чем прокси в данном случае был бы лучше, чем проброс портов.
На внешний интерфейс GATEWAY разрешено стучаться трем ip. По сути, это просто торчащее наружу API для трех удаленных адресов.
А на ближайшее будущее - планируется перенос приложения с сервака iis на linsrv в виде пачки docker-контейнеров. Постепенно, понемножку, чтобы в общем приложение всегда было рабочим. А потом и полностью отказаться от iis, а следовательно, и от проброса портов на него
- Двойной проброс порта во внутреннюю сеть, Licha Morada, 22:55 , 10-Июн-20 (7)
> Честно говоря, мне не понятно, чем прокси в данном случае был бы
> лучше, чем проброс портов.
> На внешний интерфейс GATEWAY разрешено стучаться трем ip. По сути, это просто
> торчащее наружу API для трех удаленных адресов.Причин много разных. В каких-то случаях будут более существенны одни из них, в каких-то - другие.
Например:
- Обратный прокси сервер ведёт компактные и удобочитаемые логи. Можно меньше прибегать к снифферу при поиске источника проблем.
- До настоящего веб приложения долетают только заведомо корректные HTTP запросы, а не какой попало мусор который послали в открытый порт. Дешовая защита от атак, эксплуатирующих особенности сетевого уровня, типа Slowloris.
- Легко публиковать не весь корень веб сервера апстрима, где может быть админка или другие приложения, а только избранные пути.
- Централизованное терминирование сессий TLS позволяет снизить риск ошибок конфигурации.
- Легко контролировать текущую конфигурацию "что куда и как пробрасывается" и делегировать поддержку.
- Удобно стандартизировать. Одно и то-же решение покрывает множество кейсов, от простого "опубликовать в интернете" до баланисровки нагрузки и кэширования статичного контента.
- Решение находится на одном и том-же уровне абстракции (веб сервис) что и задача (опубликовать в Интернете).
- И т.д. > А на ближайшее будущее - планируется перенос приложения с сервака iis на
> linsrv в виде пачки docker-контейнеров. Постепенно, понемножку, чтобы в общем приложение
> всегда было рабочим. А потом и полностью отказаться от iis, а
> следовательно, и от проброса портов на него Хороший план. Докерские best practices всё равно рекомендуют reverse proxy. Имеет смысл с него и начать, используя IIS в качестве апстрима для всех сервисов, и постепенно переводя их куда надо.
|
Версия для распечатки
