Routing question

[Privet]

Вчера я лихо настроил DMZ и успокоился. Сегодня обнаружил, что у меня есть доступ к серверной сетке с самого роутера. Я могу зайти по ssh на любой сервер, но (блин!!!) я не могу заходить на сервера с домашнего компьютера. Пытался делать route и forwarding, но ничего не получается.

Роутер в домашней подсетке: 192.168.1.1/24
Роутер в серверной подсетке: 192.168.10.1/24
Домашний компьютер: 192.168.1.100/24
Одна из VM : 192.168.10.22/24

ssh 192.168.10.1 -> 192.168.10.22 - работает
ssh 192.168.1.100 -> 192.168.10.22 - нет

Могу только по ssh на роутер, а дальше уже на сервер.

Что я должен делать?
Желотельно, какие конкретно src, dst, port, proto и пр.

[PavelM]

Вчера я лихо настроил DMZ и успокоился. Сегодня обнаружил, что у меня есть доступ к серверной сетке с самого роутера. Я могу зайти по ssh на любой сервер, но (блин!!!) я не могу заходить на сервера с домашнего компьютера. Пытался делать route и forwarding, но ничего не получается.

Роутер в домашней подсетке: 192.168.1.1/24
Роутер в серверной подсетке: 192.168.10.1/24
Домашний компьютер: 192.168.1.100/24
Одна из VM : 192.168.10.22/24

ssh 192.168.10.1 -> 192.168.10.22 - работает
ssh 192.168.1.100 -> 192.168.10.22 - нет

Что я должен делать?

Раутер имеет интерфейсы в обеих сетях, поэтому добавлять route смысла нет, т.к. он и так знает где какая сеть.
Я думаю дело в закрытых портах, т.е. надо добавить строчку в IPtables (так в ddwrt) чтобы позволить следующие соединения:

Source IP : 192.168.1.0/24
Source port: Any
Destination: 192.168.10.0/24
Destination port: 22

И позволить обратные пакеты.

[PavelM]

Если использовать не iptables а фаервол в OpenWRT это должно выглядеть как-то так

# Allow the port 22 to DMZ from LAN
config 'rule'
option 'src' 'lan'
option 'dest' 'dmz'
option 'proto' 'tcp'
option 'dest_port' '22'
option 'target' 'ACCEPT'

[Privet]

Я примерно вокруг этого крутился. Нарисовал точно по Вашему совету:

Code: Select all

config rule
	option name 'ssh-dmz'
	option src 'lan'
	option dest 'dmz'
	option proto 'tcp'
	option family 'ipv4'
	option dest_port '22'
	option target 'ACCEPT'

Только добавил family
Рестартанул firewall. Не работает. Кстати, пинги идут, но для этого у меня есть специальная настройка:

Code: Select all

config redirect
	option target 'DNAT'
	option dest 'dmz'
	option name 'ping-dmz'
	option proto 'icmp'
	option family 'ipv4'
	option dest_ip '192.168.10.1'
	option src 'dmz'

Я также пытался делать для 22 почти такой как Ваш, но redirect (DNAT и ACCEPT). Я увы не знаю чем отличаются rule и redirect (имею в виду действием).

[Privet]

Добавил такой nat:

Code: Select all

config redirect
	option enabled '1'
	option target 'SNAT'
	option src 'lan'
	option dest 'dmz'
	option src_dip '192.168.10.1'
	option name 'ssh-dmz-nat'
	option proto 'tcp udp'

Заработало. Только не знаю насколько это правильно.

P.S. Предыдущий route убрал

[PavelM]

Я примерно вокруг этого крутился. Нарисовал точно по Вашему совету:

Code: Select all

config rule
	option name 'ssh-dmz'
	option src 'lan'
	option dest 'dmz'
	option proto 'tcp'
	option family 'ipv4'
	option dest_port '22'
	option target 'ACCEPT'

Документация говорит

The iptables rules generated for this section rely on the state match which needs connection tracking to work. At least one of the src or dest zones needs to have connection tracking enabled through either the masq or the conntrack option.

Попробуйте добавить следующее в конфигурацию зоны lan.

option conntrack '1'

Я также пытался делать для 22 почти такой как Ваш, но redirect (DNAT и ACCEPT). Я увы не знаю чем отличаются rule и redirect (имею в виду действием).

Redirect изпользуется когда подменяется (NAT) адрес назначения (destination), например при запросе приходящем из Интернета на публичный айпи адрес подменяется на локальный айпи.

[PavelM]

Добавил такой nat:

Code: Select all

config redirect
	option enabled '1'
	option target 'SNAT'
	option src 'lan'
	option dest 'dmz'
	option src_dip '192.168.10.1'
	option name 'ssh-dmz-nat'
	option proto 'tcp udp'

Заработало. Только не знаю насколько это правильно.

P.S. Предыдущий route убрал

Ну это как бы более сложный вариант, но работать будет.
Тут адрес Вашего домашнего компьютера подменяется на адрес раутера при выходе в DMZ.
Т.е. сервер видит Ваш трафик как трафик приходящий с раутера а не с Вашего реального айпи.

P.S. UDP можно убрать. Не нужен он да и тяжело его правильно контролировать. Не знаю как это реализовано в OpenWRT.

[Privet]

Извините, отлучался и не ответил сразу.

Я примерно вокруг этого крутился. Нарисовал точно по Вашему совету:

Code: Select all

config rule
	option name 'ssh-dmz'
	option src 'lan'
	option dest 'dmz'
	option proto 'tcp'
	option family 'ipv4'
	option dest_port '22'
	option target 'ACCEPT'

Документация говорит

The iptables rules generated for this section rely on the state match which needs connection tracking to work. At least one of the src or dest zones needs to have connection tracking enabled through either the masq or the conntrack option.

Попробуйте добавить следующее в конфигурацию зоны lan.

option conntrack '1'

Стыдно признаться, но объяснения не понял. Завтра с утра перечитаю, может, на свежую голову дойдёт.
Тем не менее, я попробовал этот вариант. К сожалению, не получилось:

Warning: Option @rule[9].conntrack is unknown

...

Я также пытался делать для 22 почти такой как Ваш, но redirect (DNAT и ACCEPT). Я увы не знаю чем отличаются rule и redirect (имею в виду действием).

Redirect изпользуется когда подменяется (NAT) адрес назначения (destination), например при запросе приходящем из Интернета на публичный айпи адрес подменяется на локальный айпи.

Этот механизм проще для понимания (для меня, во всяком случае), но т.к. я плохо знаком с предметом, то не могу оценить насколько он разумен и безопасен. Не знаешь откуда беды ждать.

[StrangerR]

Спасибо большое за совет! Обязательно это сделаю.
Кстати, какой Вы прокси используете? Не nginx, случайно?

Штатную апачу - ее хватает а _лучшее враг хорошего_. Но народ юзает nginx.

Один черт. Главное - конфигурить так чтобы без имени хоста получать пустой экран, и только с правильным именем (например forum.privet.com) получать приложение. Если проблемы при доступе через внутреннюю сетку то там откуда доступ прописать имя в hosts файле.

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

Метода уменьшает поток сканирований приложения раз так в тысячу. Конечно, от целенаправленной атаки да в данном случае (когда есть в интернете ссылки на сайт то есть легко найти его имя) не спасает но от тупых сканеров, которых в сети легион - вполне...

Идею выше правильно нарисовали. Я потом тоже нарисую, вариант.

[StrangerR]

Имеет ли большой смысл, с точки зрения безопасности, пустить трафик на веб-сервер через промежуточный хост, чтобы изолировать сервер от внешней сети? Если да, то как это лучше сделать?
Я сделал такой фокус через nat, но получилось так, что веь трафик на веб-сервер шёл с одного ip. Не годится.

1. Имеет, но только если прокси еще и фильтрует трафик. Простой обратный прокси без фильтрации никакой пользы для защиты не несет.

2. Прокси будет подменять адрес клиента своим и это нормально. Надо настраивать заголовки X-Forwarded-For. Некоторые прокси можно настроить чтобы они адрес клиента сохраняли, но тогда имейте ввиду что сервер обратный пакет будет посылать напрямую клиенту (не через прокси) и мы получим асимметричное соединение и возможные проблемы с фаерволами на пути которые будут видеть запросы уходящие к одному айпи, а ответы приходящие от другого и блокировать последние.

Даже простейший прокси, если он пускает только по имени (а если имя другое то пускает на пустой лист) - обрезает процентов 99% сканирований.

X- заголовки и так прокси все ставят. Настраивать сохранение IP не нужно если не используется на самом форуме для фильтрования. Нужно конечно сохранять логи на прокси. Еще не вредно прокси делать на самой новой ОС и там ставить авто апдейты, благо прокси не связан ограничениями на версии пхп и прочего на что завязан форум.

Ну и на файреволле адрес сервера и порт при входе на него подменяются так что наружу он торчит на внешнем адресе. Адрес с которого идет запрос не подменяется, то есть сервер (ну или прокси) видит его нормально без замены. Я еще часто делают не статику 1:1 а оставляю global PNAT (когда исходящий трафик идет весь с одного адреса) а вот именно конкретно на порт 443 прописываю статику (то есть по внешнему адресу сервера можно соединиться только с портом 443, причем даже не потому что акцесс лист а потому что другие порты вообще не транслируем на этом адресе.)

[Privet]

У меня, оказывается, неправильно были включены VM в виртуальные свичи. Даже не представляю как так можно было сделать. Кроме того, надо было вынести esxi management в другую подсетку. Начал править - наделал кучу мыслимых и немыслимых ошибок. Типа того, что вынес management в отдельный свич, но забыл к этому свичу приладить хоть какой-нибудь порт. Пришлось бежать к серверу.
Дальше надо было сменить ip у серверов. Я всё вроде подготовил, чтобы переключить в одну секунду, но забыл, что права доступа у БД привязаны, блин, к IP. При этом у меня не было доступа к серверам, т.к. они улетели в другую подсетку, которая ещё не настроена. Более того, пропала почему-то связь с клиентом esxi. Я вообще без рук оказался. С матами-перематами открутил всё обратно.
Связь с серверами опять потеряна. Какие-то белые чёртики всё под руки лезут и мешают, мешают...

Чесслово, не хотел бы я работать админом. Не для меня. Моё дело всегда было найти какую-нибудь залипуху в системе (софтверной или хардверной - не важно) или найти решение там, где его принципиально нет. В этом мне не было равных, но изо дня в день нудно поддерживать систему чтобы не упало, да ещё ждать атаки откуда не попадя - лучше я умру.

[PavelM]

Стыдно признаться, но объяснения не понял. Завтра с утра перечитаю, может, на свежую голову дойдёт.
Тем не менее, я попробовал этот вариант. К сожалению, не получилось:

Warning: Option @rule[9].conntrack is unknown

В общих чертах смысл таков. "config rule" настраивает фильтр для айпи пакетов только в одном направлении. Для возврата пакетов надо либо прописывать зеркально обратный "config rule", что не есть хорошо, либо включить авто-поддержку соединений TCP в "config zone" . Насколько я понимаю, опция Conntrack для этого и нужна. Раутер будет запоминать что соединение тисипи инициировано из зоны lan в зону dmz и будет возвращать обратные пакеты автоматически. (т.н. Stateful Firewall) Но то что Вы сделали с НАТ - тоже неплохо, даже лучше с точки зрения защиты т.к. из dmz не видно Ваших реальных айпи на домашней сети.

[Privet]

Сделал, конечно, всё. Всё ходит вроде бы как надо. Всё пингуется. Сейчас осталось отодвинуть сервера подальше от внешней сети и подшаманить настройки веб-сервера по совету StrangerR.
Спасибо большое всем ответившим за подробные объяснения. Мне это здорово помогло в понимании многих вещей и в практической настройке всей системы. Можно сколько угодно читать толстые гроссбухи, но без практики трудно доходить до всего самому. До сих пор до конца не понимаю, что происходит в системе.

Например, я создал на сервере две независимые зоны: 192.168.10.1,24 - loc, куда включены idrac + esxi и 192.168.20.1/24 - dmz для серверов. Домашняя сетка теперь 192.168.1.1|24. Сетку loc вижу (ping, ssh, http) без всяких настроек. Сетку dmz вижу только после добавления snat + route + icmp forwerding. Причём даже после ребута роутера и дом. компьютера, но я всё равно для обоих сделал симметричные настройки:

Code: Select all

config redirect
	option target 'SNAT'
	option src 'lan'
	option dest 'dmz'
	option src_dip '192.168.20.1'
	option name 'dmz-nat'
	option proto 'all'

config rule
	option target 'ACCEPT'
	option name 'dmz-route'
	option family 'ipv4'
	option proto 'all'
	option dest_ip '192.168.20.1'
	option src 'lan'
	option dest 'dmz'

config rule
	option target 'ACCEPT'
	option name 'dmz-ping'
	option family 'ipv4'
	option proto 'icmp'
	option dest_ip '192.168.20.1'
	list icmp_type 'echo-reply'
	option src 'lan'
	option dest 'dmz'

"Улучшать" без нужды больше не буду.

У меня есть ещё небольшие вопросики.
Вирт. свичи, что в vmware позволяют объединять порты в группы и назначать им VLAN ID. В роутере зоны тоже тоже каждая имеет свой VLAN ID. Эти VLAN ID независимы?

[PavelM]

Даже простейший прокси, если он пускает только по имени (а если имя другое то пускает на пустой лист) - обрезает процентов 99% сканирований.

Согласен, это и есть фильтр

[PavelM]

Вирт. свичи, что в vmware позволяют объединять порты в группы и назначать им VLAN ID. В роутере зоны тоже тоже каждая имеет свой VLAN ID. Эти VLAN ID независимы?

А порт идущий от виртуального свитча к раутеру настроен как VLAN Trunk?
Если так, то VLAN ID на свитче должны соответствовать VLAN ID соответствующих зон на раутере.
Если между свитчем и раутером транка нет, то информация о номерах VLAN не распространяется от одного устройства к другому и номера могут быть независимы.