Вариант для распечатки		Пред. тема | След. тема
Форум Информационная безопасность (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.ru/openforum/vsluhforumID10/5518.html https://www.opennet.ru/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.ru/openforum/vsluhforumID10/5518.html > https://www.opennet.ru/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 | Индекс форумов | Темы | Пред. тема | След. тема