Routing question

[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 не распространяется от одного устройства к другому и номера могут быть независимы.

[Privet]

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

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

Упс! Первый раз такие слова слышу.
В документации сказано:

To configure Virtual Switch (vSwitch) VLAN Tagging (VST) on an ESXi/ESX host:
Assign a VLAN to a portgroup(s). The supported VLAN range is 1-4094.
Reserved VLAN IDs:
VLAN ID 0 (zero) Disables VLAN tagging on port group (EST Mode)
VLAN ID 4095 Enables trunking on port group (VGT Mode)

У меня сейчас везде стоят VLAN ID = 0. Значит, как я понимаю, у меня выключены оба режима - trunking и tagging.
По моему разумению, для меня это не имеет никакого значения. Есть только один моментик.
Сейчас у меня на сервере три свича - external (идёт мимо роутера), dmz (объединяет сервера), local (idrac, esxi). Для external используются два порта чисто для резервирования. Свичи dmz и local имеют по одному порту. 1. Правильно ли я понимаю, что эти свичи можно объединить в один и использовать два порта для резервации, а потоки разделять по IP и по VLAN ID? 2. Есть ли в этом смысл?

P.S. Мне уже подсказали, что 4 серверных порта образуются двумя чипами. Если использовать в каждом свиче по два порта из разных чипов, то работоспособность системы сохранится при выходе из строя одного из чипов. Вероятность, думаю, небольшая, но всё-же...

[StrangerR]

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

Это один и тот же ИД. Но все зависит от того как вы включаете порт хоста в свитч. Обычно включают в режиме TRUNK (то есть на свитче прописывают switchport mode trunk) и тогда свитч выдает и принимает пакеты с тагом, и тагом является как раз оное ID VLAN-а. То есть у меня например в простейшем случае стоит свитч (ну по жизни два), в нем куча VLAN, порт куда воткнут хост в режиме trunk
(и еще стоит spanning-tree portfast trunk чтобы он не думал по минуте при включении порта после его отключения), а в vSwitch те же VLAN прописаны как Virtual Networks с теми же тагами. И все. Я любой сервер включаю в любую из этих сетей. Логически, я просто имею физический свитч затем воткнутый в него именно транком виртуальный и затем любую VM подключаю к одно или несколко VLAN.

Но я могу включить порт свитча и в режим access и назначить туда одну VLAN и тогда этот таг на порту не виден. Тогда у меня vSwitch будет весь иметь соединение ровной с одной VLAN и никаикх тагов в сетях на нем описывать не нужно.

(Мы так включаем порты DRAC - хотя могли бы и с тагом включать.)

[StrangerR]

То есть - если у вас на свитче три сети, HOME, DMZ, OUTSIDE, а у хоста 4 порта, то есть 2 варианта.
1) Взять ОДИН порт включить его в свитч на свитче прописать режим порта ТРАНК в vSwitch завести 3 сети с разными тагами. Иметь ОДИН vSwitch.
2) Сделать 3 порта на свитче, на каждый вывести свою сеть. В хосте сделать 3 vSwitch на каждом по одной сети. Сети на разных свитчах назвать HOME, DMZ, OUTSIDE. Включить 3 порта хоста в 3 разных порта свитча.

Итог одинаковый но во втором больше портов использовали но зато больше скорость так как у вас 3 порта. Можно комбинировать (и часто так делают, кстати у нас так было раньше кое в каких центрах пока я все OUTSIDE не переделал тоже в VLAN-ы) - например OUTSIDE отдельно а остальное на одном транке. По жизни свитчей 2 и хост воткнут транком в 2 свитча для реданданси.

[Privet]

Спасибо большое! Я уже начинаю что-то понимать. Оставлю два вирт. свича. Один наружу, а через другой пущу dmz и loc. Home роутера не покидает. Я потом покажу что получилось. Только бы не заиграться. У меня есть такая наклонность - ставить и экспериментировать с новыми системами, которые не всегда ещё отлажены. Администраторы обычно тщательно планируют каждый шаг, а потом делают, а у меня есть склонность делать и думать одновременно.

[StrangerR]

Вот наверное самое разумное.

Там еще не запутайтесь с Native Network в 802.1q, чтобы авторам этого стандарта икалось... Она без тага идет и по умолчанию VLAN1 по моему. У меня некоторые девайсы не любят когда ее указывают как tag 1.

(Лучше просто VLAN1 не использовать, но обычно _уже поздно, уже использовали_)

[Privet]

В первоначальных настройках роутера (точнее OpenWrt) VLAN1 назначено для LAN, т.е. домашней сетке, но она идёт только потребителям. По серверу не гуляет. Легко меняется, но я не рискую, т.к. не могу просчитать последствия. Не перекосятся ли настройки?

[StrangerR]

Да нет, просто добавьте на vSwitch (если он включен транком) сначала сеть без VLAN а потом с ID 1, и найдите какая даст возможность попадать в HOME. И все. Одно из двух сработает, и назовете HOME.