Да, про это я уже тоже подумал) К сожалению, пока физически не могу это сделать - нужно реорганизовать структуру сети (мне всё это счастье по наследству досталось). На данный момент я купировал проблему: - Заметил, что незадолго до атаки появлялось established-соединение, инициированное регистратором, а соединялся он рандомно с какой-то частью мира (Австралия, Китай, Германия и т.п.); - Я в итоге создал список "белых" адресов, с которых клиент мог продолжать пользоваться XMEye-сервисом (клиент потерял мобильность... Но лучше уж пока так); - Все остальные инициированные регистратором соединения "вовне" я зарезаю на шаге /ip firewall raw (сразу после accept для "белого"). Вроде помогло... Посмотрим. PS Видеорегистраторы все разношерстные - ребята с первой линии с понедельника начнут кататься и перепрошивать их... Надеюсь, поможет) PPS Я так и не догадался, как бы мне автоматически положить адрес жертвы (атакуемого ip) в address-list , основываясь на множественном подключении к нему? Я то ли не на том шаге пытаюсь "поймать" количество коннектов..?

Под множественными подключениями подразумевается: Established connections <ip-регистратора>:<некий фикс. исх. порт> <==> <ip-жертвы>:<порты 1,2,3,...34823,... и пока ресурсы микротика позволяют>

Это видеорегистратор, подключенный к облаку XMEye Прокинутый порт, конечно, есть - уже сменен на нестандартный... Но пока не помогает. Возможно, зараза уже внутри. С ним могу взаимодействовать только на уровне панели управления. (давайте не развивать эту тему - какое это г... - я уже знаю)

Вайпуть его.

Да, про это я уже тоже подумал) К сожалению, пока физически не могу это сделать - нужно реорганизовать структуру сети (мне всё это счастье по наследству досталось). На данный момент я купировал проблему: - Заметил, что незадолго до атаки появлялось established-соединение, инициированное регистратором, а соединялся он рандомно с какой-то частью мира (Австралия, Китай, Германия и т.п.); - Я в итоге создал список "белых" адресов, с которых клиент мог продолжать пользоваться XMEye-сервисом (клиент потерял мобильность... Но лучше уж пока так); - Все остальные инициированные регистратором соединения "вовне" я зарезаю на шаге /ip firewall raw (сразу после accept для "белого"). Вроде помогло... Посмотрим. PS Видеорегистраторы все разношерстные - ребята с первой линии с понедельника начнут кататься и перепрошивать их... Надеюсь, поможет) PPS Я так и не догадался, как бы мне автоматически положить адрес жертвы (атакуемого ip) в address-list , основываясь на множественном подключении к нему? Я то ли не на том шаге пытаюсь "поймать" количество коннектов..?

Да с регистраторами-то разберёмся) Но это тема про Микротики) Мне уже просто интересно стало "а как"?)

Если они множественные. Считайте их и лимитом добавляйте. Есть аналогия по rdp brute force. Там тоже лимитом рубится. Берётся время и считаются соеденения. Если их больше кидаем в лист и так далее

А ещё лучше вырубить xmey облако

А ещё лучше вырубить xmey облако

По хорошему да, вырубить его, а до рега поднять впн, если надо смотреть снаружи

Да, про это я уже тоже подумал) К сожалению, пока физически не могу это сделать - нужно реорганизовать структуру сети (мне всё это счастье по наследству досталось). На данный момент я купировал проблему: - Заметил, что незадолго до атаки появлялось established-соединение, инициированное регистратором, а соединялся он рандомно с какой-то частью мира (Австралия, Китай, Германия и т.п.); - Я в итоге создал список "белых" адресов, с которых клиент мог продолжать пользоваться XMEye-сервисом (клиент потерял мобильность... Но лучше уж пока так); - Все остальные инициированные регистратором соединения "вовне" я зарезаю на шаге /ip firewall raw (сразу после accept для "белого"). Вроде помогло... Посмотрим. PS Видеорегистраторы все разношерстные - ребята с первой линии с понедельника начнут кататься и перепрошивать их... Надеюсь, поможет) PPS Я так и не догадался, как бы мне автоматически положить адрес жертвы (атакуемого ip) в address-list , основываясь на множественном подключении к нему? Я то ли не на том шаге пытаюсь "поймать" количество коннектов..?

У ребят с первой линии есть патченная прошивка? Официозы не фиксят косяк, я только знаю, где энтузиаст, обнаруживший как раз эту атаку, таки осилил пропатчить бинарно эту пакость.

У ребят с первой линии есть патченная прошивка? Официозы не фиксят косяк, я только знаю, где энтузиаст, обнаруживший как раз эту атаку, таки осилил пропатчить бинарно эту пакость.

Патченых прошивок - думаю, что ещё нет у ребят (да и зоопарк там с DVR: HSY-A1004NS, HSY-A1008NM, N1008G5, A1004N-C, N1004F, N1008F). В общем, в индивидуальном порядке будем решать с ними... Вчера я только разобрался, откуда ноги растут и купировал проблему (а точнее, только ее симптомы). Я отлично осознаю, что надо устранять причину всей этой катавасии - но удаленно не могу это сделать) Потому и начал с того, что мне доступно прямо сейчас. Сервис "Cloud" в настройках регистраторов уже отрубили, кстати - но это не помогло. В vlan уведу видеонаблюдение после реорганизации физического подключения. Доступность порта для CMS уже ограничил (помогло, но клиент из-за этого потерял мобильность - пока терпит...). VPN для восстановления утерянной мобильности - хорошая идея - сделаю... Как правильно использовать connection-limit - тоже разберусь... (переспал с этой мыслью - появились идеи - буду проверять... Уж простите, у меня за плечами только курс Mikrotik MTCNA - так глубоко я еще не закапывался)

Патченых прошивок - думаю, что ещё нет у ребят (да и зоопарк там с DVR: HSY-A1004NS, HSY-A1008NM, N1008G5, A1004N-C, N1004F, N1008F). В общем, в индивидуальном порядке будем решать с ними... Вчера я только разобрался, откуда ноги растут и купировал проблему (а точнее, только ее симптомы). Я отлично осознаю, что надо устранять причину всей этой катавасии - но удаленно не могу это сделать) Потому и начал с того, что мне доступно прямо сейчас. Сервис "Cloud" в настройках регистраторов уже отрубили, кстати - но это не помогло. В vlan уведу видеонаблюдение после реорганизации физического подключения. Доступность порта для CMS уже ограничил (помогло, но клиент из-за этого потерял мобильность - пока терпит...). VPN для восстановления утерянной мобильности - хорошая идея - сделаю... Как правильно использовать connection-limit - тоже разберусь... (переспал с этой мыслью - появились идеи - буду проверять... Уж простите, у меня за плечами только курс Mikrotik MTCNA - так глубоко я еще не закапывался)

Ну, по порядку, "названия" от переклейщиков шильдиков мало помогут, нужны версии прошивок, так как их именует XM - всё остальное ребрендеринг в худшем смысле этого слова ) Отключить облака - может уже не помочь, как я понял, появился новый вид "нагрузки", или с их помощью умудрились заразить компы в локалке, и они теперь локально дёргают реги, чтобы те гоняли трафик (слишком сложно на лету по удаленке залить прошивку, да еще и встроить в неё вредонос, так чтобы ничего не сломать). В общем, было замечено тепперь, что не только с пробросом портов начали реши шалить, но и облачные, и уже безоблачные, просто с доступом к интернету. Точный механизм пока нет возможности расследовать. Вынесение в закрытый контур с доступом в него через впн - решит проблему, при этом сами реги можно в инет не выпускать. Тем более сейчас китайские облака начали работать через раз. С connection limit идея интересная, но в данном случае не обязательная, но в качестве нового скилла, вполне себе идея )

Ну, по порядку, "названия" от переклейщиков шильдиков мало помогут, нужны версии прошивок, так как их именует XM - всё остальное ребрендеринг в худшем смысле этого слова ) Отключить облака - может уже не помочь, как я понял, появился новый вид "нагрузки", или с их помощью умудрились заразить компы в локалке, и они теперь локально дёргают реги, чтобы те гоняли трафик (слишком сложно на лету по удаленке залить прошивку, да еще и встроить в неё вредонос, так чтобы ничего не сломать). В общем, было замечено тепперь, что не только с пробросом портов начали реши шалить, но и облачные, и уже безоблачные, просто с доступом к интернету. Точный механизм пока нет возможности расследовать. Вынесение в закрытый контур с доступом в него через впн - решит проблему, при этом сами реги можно в инет не выпускать. Тем более сейчас китайские облака начали работать через раз. С connection limit идея интересная, но в данном случае не обязательная, но в качестве нового скилла, вполне себе идея )

По поводу "ребрендинга" этих DVR - я уже вчера осознал проблему, и потому пока лично не погружался в это счастье) А версии текущих прошивок - постараюсь/придется добыть) Антивирусную утилитку на соседских компах, конечно, прогнали... - и ничего не нашли. Но если там какой-то "легальный" скрипт/утилита используется - его сложно будет поймать... Тут отличным решением будет реорганизовать сеть и выделить видеонаблюдение в vlan - это я уже планирую... connection-limit - это уже действительно для саморазвития) А то вчера сижу в консоли, наблюдаю как DVR опять начал кого-то атаковать - инструмент вроде есть в руках, а использовать его не умею)) - позор) Надо научиться)

По поводу "ребрендинга" этих DVR - я уже вчера осознал проблему, и потому пока лично не погружался в это счастье) А версии текущих прошивок - постараюсь/придется добыть) Антивирусную утилитку на соседских компах, конечно, прогнали... - и ничего не нашли. Но если там какой-то "легальный" скрипт/утилита используется - его сложно будет поймать... Тут отличным решением будет реорганизовать сеть и выделить видеонаблюдение в vlan - это я уже планирую... connection-limit - это уже действительно для саморазвития) А то вчера сижу в консоли, наблюдаю как DVR опять начал кого-то атаковать - инструмент вроде есть в руках, а использовать его не умею)) - позор) Надо научиться)

Там если камеры ip то и они стучатся в облако).

Там если камеры ip то и они стучатся в облако).

Да, это я тоже заметил) Их как раз заблокировал без всяких сожалений: им нужно только видеорегистратор видеть - и больше ничего)

Ну сделать впн до точки человеку на wg и все решится. Он даже не заметит

Да, это я тоже заметил) Их как раз заблокировал без всяких сожалений: им нужно только видеорегистратор видеть - и больше ничего)

Им ещё надо ntp. Впн с allowed только до точки регика и все. Без 0.0.0.0

Ну сделать впн до точки человеку на wg и все решится. Он даже не заметит

По сути - да) Но я под это дело и остальной всплывший бардак хочу прибрать)

Им ещё надо ntp. Впн с allowed только до точки регика и все. Без 0.0.0.0

NTP-Server тоже уже поднял на микротике. А на DVR: NTP-Client - это единственный сервис, который я оставил включенным. Стоп... Или NTP-клиент y камер?.. Да нет... Он мне вроде не нужен... Видео клиент смотрит только с регистратора (да и парочка точек с аналоговыми камерами).

NTP-Server тоже уже поднял на микротике. А на DVR: NTP-Client - это единственный сервис, который я оставил включенным. Стоп... Или NTP-клиент y камер?.. Да нет... Он мне вроде не нужен... Видео клиент смотрит только с регистратора (да и парочка точек с аналоговыми камерами).

Ну если рег умеет синхронить время на камерах то да. А если парк разный то нужен

Ну если рег умеет синхронить время на камерах то да. А если парк разный то нужен

Проверю... Спасибо)

Ntp нужно внутри сети разворачивать

Ntp нужно внутри сети разворачивать

угу, типовое решение - пара виртуалок с ntpd которые ходят в интернет на кучу серверов а отдают внутрь сети по всем возможным протоколам (и 2 адреса без dns внутри сети)

Да эти сервисы можно на любые сервера прицепом поднимать

Которые в инет ходят конечно))

ну, в целом - да, вопрос вкуса (замешивать/не замешивать)

через отдельные - проще контролировать трафик.

Кто-нибудь ставил в контейнер sing-box?

Кто-нибудь ставил в контейнер sing-box?

А что с ним не так?

А что с ним не так?

В gui наблюдаю картину, что нет connections. Пробовал даже роутер с чистого листа настроить, один фиг.

Всем доброго времени суток. Провайдер выдал дополнительную подсеть /29 маршрутизируя её на меня, на мой основной IP. Столкнулся с таким впервые. Хотелось бы натить белые IP адреса в локалку, т.е. внутри локалки оставить серые адреса, а через нат разрулить всё, что нужно. Как пример: add action=dst-nat chain=dstnat dst-address=БЕЛЫЙ_IP dst-port=443 protocol=tcp to-addresses=192.168.10.222 to-ports=443 add action=src-nat chain=srcnat dst-address-list=!LocalNet out-interface=ether1 src-address=192.168.10.222 to-addresses=БЕЛЫЙ_IP Проблема в том, что правила прописаны, но ничего не работает. Провайдер говорит, что ваш микрот не маршрутизирует трафик. Как быть, куда копнуть?

Всем доброго времени суток. Провайдер выдал дополнительную подсеть /29 маршрутизируя её на меня, на мой основной IP. Столкнулся с таким впервые. Хотелось бы натить белые IP адреса в локалку, т.е. внутри локалки оставить серые адреса, а через нат разрулить всё, что нужно. Как пример: add action=dst-nat chain=dstnat dst-address=БЕЛЫЙ_IP dst-port=443 protocol=tcp to-addresses=192.168.10.222 to-ports=443 add action=src-nat chain=srcnat dst-address-list=!LocalNet out-interface=ether1 src-address=192.168.10.222 to-addresses=БЕЛЫЙ_IP Проблема в том, что правила прописаны, но ничего не работает. Провайдер говорит, что ваш микрот не маршрутизирует трафик. Как быть, куда копнуть?

Микротики друг друга пингуют?

Микротики друг друга пингуют?

Т.е.? У меня один микрот

Т.е.? У меня один микрот

Сути не меняет, на другом конце же какое-то устройство есть

Сути не меняет, на другом конце же какое-то устройство есть

Тогда уточните, что именно должно пинговаться?!) Я чёт пока не пойму)

29 маска это 6 устройств. Одно из них микротик

Всем доброго времени суток. Провайдер выдал дополнительную подсеть /29 маршрутизируя её на меня, на мой основной IP. Столкнулся с таким впервые. Хотелось бы натить белые IP адреса в локалку, т.е. внутри локалки оставить серые адреса, а через нат разрулить всё, что нужно. Как пример: add action=dst-nat chain=dstnat dst-address=БЕЛЫЙ_IP dst-port=443 protocol=tcp to-addresses=192.168.10.222 to-ports=443 add action=src-nat chain=srcnat dst-address-list=!LocalNet out-interface=ether1 src-address=192.168.10.222 to-addresses=БЕЛЫЙ_IP Проблема в том, что правила прописаны, но ничего не работает. Провайдер говорит, что ваш микрот не маршрутизирует трафик. Как быть, куда копнуть?

А белые адреса на самом тике прописаны?

А белые адреса на самом тике прописаны?

Нет. А должны?

29 маска это 6 устройств. Одно из них микротик

Речь идёт про маршрутизируемую подсеть на себя и НАТ.

Ну да... Укажите их на интерфейс и потом правилами разделите между устройствами

Нет. А должны?

Лучше на роутере их привязать и использовать nat 1:1

Лучше на роутере их привязать и использовать nat 1:1

Это не твой блок pi адресов. Как следствие и привязывать его на конечных устройствах не очень хорошая практика.

Это не твой блок pi адресов. Как следствие и привязывать его на конечных устройствах не очень хорошая практика.

Как это не его? Ему провайдер выдал и они его пока не заберут

Ну да... Укажите их на интерфейс и потом правилами разделите между устройствами

ChatGPT другого мнения: Если ваш провайдер маршрутизирует подсеть через ваш основной белый IP-адрес, и вы хотите использовать эту подсеть только для NAT (без назначения IP-адресов напрямую устройствам), на MikroTik это можно настроить через несколько шагов. ### Сценарий - Основной белый IP-адрес (например, 203.0.113.10/30) — предоставлен провайдером для подключения к интернету. - Маршрутизируемая подсеть (например, 203.0.114.0/29) — провайдер маршрутизирует её через ваш основной белый IP. - Вы хотите использовать IP-адреса из маршрутизируемой подсети для NAT, чтобы скрыть внутреннюю сеть за этими IP-адресами. ### Шаги по настройке NAT для маршрутизируемой подсети #### 1. Подключение к MikroTik Подключитесь к вашему маршрутизатору через Winbox, SSH или WebFig. #### 2. Назначение основного белого IP-адреса на WAN-интерфейс Сначала необходимо назначить основной IP-адрес, предоставленный провайдером, на WAN-интерфейс. - Перейдите в IP → Addresses. - Нажмите +, чтобы добавить новый IP-адрес. - В поле Address введите основной белый IP-адрес, например, 203.0.113.10/30. - В поле Interface выберите WAN-интерфейс, например, ether1. - Нажмите OK. Пример команды через CLI: /ip address add address=203.0.113.10/30 interface=ether1 #### 3. Добавление маршрута по умолчанию (Default Route) Чтобы маршрутизировать весь интернет-трафик через основной белый IP, нужно добавить маршрут по умолчанию. - Перейдите в IP → Routes. - Нажмите +. - В поле Dst. Address введите 0.0.0.0/0. - В поле Gateway введите IP-адрес шлюза провайдера (например, 203.0.113.9). - Нажмите OK. Пример команды через CLI: /ip route add dst-address=0.0.0.0/0 gateway=203.0.113.9 #### 4. Настройка NAT для маршрутизируемой подсети Теперь нужно настроить NAT, чтобы внутренние устройства могли выходить в интернет, используя белые IP-адреса из маршрутизируемой подсети. 1. Перейдите в IP → Firewall → NAT. 2. Нажмите +, чтобы создать новое правило. 3. На вкладке General: - В поле Chain выберите srcnat. - В поле Out. Interface выберите WAN-интерфейс (например, ether1), через который идет интернет. 4. На вкладке Action: - В поле Action выберите src-nat. - В поле To Addresses введите диапазон IP-адресов из вашей маршрутизируемой подсети (например, 203.0.114.1-203.0.114.6). 5. Нажмите OK. Пример команды через CLI: /ip firewall nat add chain=srcnat out-interface=ether1 action=src-nat to-addresses=203.0.114.1-203.0.114.6 Это правило NAT заменит исходящий IP-адрес внутренней сети на один из IP-адресов маршрутизируемой подсети. #### 5. Опциональная настройка NAT с балансировкой нагрузки Если у вас несколько IP-адресов в маршрутизируемой подсети и вы хотите балансировать использование NAT между ними, можно добавить дополнительную настройку. Например, если вы хотите, чтобы каждый запрос использовал разные IP-адреса из диапазона, можно использовать src-nat с режимом переменного назначения (round-robin): - В IP → Firewall → NAT: - На вкладке General выберите srcnat. - На вкладке Action выберите netmap. - В поле To Addresses укажите диапазон IP-адресов (например, 203.0.114.1-203.0.114.6). Это позволит циклически использовать IP-адреса из диапазона. #### 6. Проверка настройки Для проверки того, что NAT работает корректно, вы можете запустить команду ping с устройства во внутренней сети и убедиться, что исходящий IP-адрес один из тех, что в маршрутизируемой подсети. Пример команды на MikroTik: ping 8.8.8.8 Вы также можете использовать команды вроде traceroute и проверить, что ваш трафик идет через правильный IP. ### Заключение 1. Основной белый IP назначается на WAN-интерфейс. 2. Маршрут по умолчанию настраивается для выхода в интернет. 3. Правило NAT настраивается таким образом, чтобы внутренние устройства использовали белые IP-адреса из маршрутизируемой подсети для выхода в интернет. 4. (Опционально) Используется балансировка нагрузки по диапазону IP-адресов для более эффективного использования маршрутизируемой подсети. Теперь вся внутренняя сеть будет выходить в интернет через ваши белые IP-адреса из маршрутизируемой подсети.

Как это не его? Ему провайдер выдал и они его пока не заберут

Как выдал так и забрал/поменял. Что ему делать с этими адресами, если провайдер поменялся? Недоступен и т.д.?

Вот у меня сейчас именно так и сделано, как и пишет ChatGPT... Но какого фига не работает, не пойму

Вот у меня сейчас именно так и сделано, как и пишет ChatGPT... Но какого фига не работает, не пойму

Делай экспорт конфигурации сюда или. Paste bin

Ну я написал как работает. Просто прописать адреса на интерфейс и правилами dst src разрулить.

Еще можно их пробросить в саму сеть и раздать на сами устройства, но это не целесообразно из-за потери 2х адресов.

Еще можно их пробросить в саму сеть и раздать на сами устройства, но это не целесообразно из-за потери 2х адресов.

Нет такой задачи. Задача с помощью nat раскидать всё, что нужно

Тогда указать все адреса на wan и раскидать

Нет такой задачи. Задача с помощью nat раскидать всё, что нужно

Если создать лупбек (пустой бридж) и повесить на него один внешний ip из /29 - то он снаружи пингуется / доступен?

Если создать лупбек (пустой бридж) и повесить на него один внешний ip из /29 - то он снаружи пингуется / доступен?

Так есть жеж уже loop back в семёрке

Тогда указать все адреса на wan и раскидать

Зачем их указывать в wan, если можно в нате указать dst-nat dst-address?

Если создать лупбек (пустой бридж) и повесить на него один внешний ip из /29 - то он снаружи пингуется / доступен?

Не пробовал, попробую

Не пробовал, попробую

Если не будет работать, то к провайдеру. А так вроде все верно.

Если не будет работать, то к провайдеру. А так вроде все верно.

Предположим, что запингуется. Ок, а где тогда косяк, почему nat не работает?

Зачем их указывать в wan, если можно в нате указать dst-nat dst-address?

Ну если адрес нигде не указан, значит его нет.... То и правила куда будут прокидывать?

Вам дали диапазон, но сами адреса нигде не висят...

Ну если адрес нигде не указан, значит его нет.... То и правила куда будут прокидывать?

nat-у все равно, он просто меняет заголовки как написано.

Ну если адрес нигде не указан, значит его нет.... То и правила куда будут прокидывать?

Адрес указан в NAT. Если я в NAT задам ICMP accept на основной белый IP, то и пинг будет. Но мне это не нужно, мне достаточно прокинуть порты во внутреннею сеть

Адрес указан в NAT. Если я в NAT задам ICMP accept на основной белый IP, то и пинг будет. Но мне это не нужно, мне достаточно прокинуть порты во внутреннею сеть

add action=dst-nat chain=dstnat in-interface=ether1 protocol=icmp to-addresses=ОСНОВНОЙ_БЕЛЫЙ_IP

Адрес указан в NAT. Если я в NAT задам ICMP accept на основной белый IP, то и пинг будет. Но мне это не нужно, мне достаточно прокинуть порты во внутреннею сеть

Эххх.. вы из тех, кто пинг снаружи запрещает :)

Эххх.. вы из тех, кто пинг снаружи запрещает :)

Да не, как раз наоборот)

К провайдеру уже обращался.. Они упорно утверждают, что ваш микрот не маршрутизирует трафик

К провайдеру уже обращался.. Они упорно утверждают, что ваш микрот не маршрутизирует трафик

Ещё раз, loopback - запинговался?

Проверю позже, пока нет возможности. Сейчас пытаюсь собрать все возможные варианты, и уже на месте проверять

Если запинговался, правила forward в firewall

Если запинговался, правила forward в firewall

вы имеете ввиду разрешить forward на ether1?

вы имеете ввиду разрешить forward на ether1?

Имею в виду разрешить соединения с флагом dstnat Посмотрите правила, которые идут по-умолчанию.

К провайдеру уже обращался.. Они упорно утверждают, что ваш микрот не маршрутизирует трафик

Сделайте как я написал, ответ 100% рабочий. На wan вешайте все адреса, что выдали. И по 2 правила на реальник с серым адресов DST SRC

Зачем?

Чтобы записать - нужен ipam. Если у провайдера действительно static route через /30 - то не надо от слова совсем.

Всем доброго времени суток. Провайдер выдал дополнительную подсеть /29 маршрутизируя её на меня, на мой основной IP. Столкнулся с таким впервые. Хотелось бы натить белые IP адреса в локалку, т.е. внутри локалки оставить серые адреса, а через нат разрулить всё, что нужно. Как пример: add action=dst-nat chain=dstnat dst-address=БЕЛЫЙ_IP dst-port=443 protocol=tcp to-addresses=192.168.10.222 to-ports=443 add action=src-nat chain=srcnat dst-address-list=!LocalNet out-interface=ether1 src-address=192.168.10.222 to-addresses=БЕЛЫЙ_IP Проблема в том, что правила прописаны, но ничего не работает. Провайдер говорит, что ваш микрот не маршрутизирует трафик. Как быть, куда копнуть?

А ваш основной IP тоже входит в эту подсеть /29?

Если запинговался, правила forward в firewall

В общем, если повесить IP из дополнительной сети на тот же интерфейс, где сидит основной, в моём случае это ether5, то дополнительный IP начинает пинговаться

В общем, если повесить IP из дополнительной сети на тот же интерфейс, где сидит основной, в моём случае это ether5, то дополнительный IP начинает пинговаться

Ну так и есть... Все дальше правила ната

И еще вы в правилах там выше писали порт 443, вам нужно только его пробросить? Или всю адресацию?

И еще вы в правилах там выше писали порт 443, вам нужно только его пробросить? Или всю адресацию?

На данный момент только 443 порт

Ну включайте правила и пробуйте подключиться. Еще бывает если нет пакетов, нужно эти правила поднять выше маскарада

Это получается обычный port forward

В общем, если повесить IP из дополнительной сети на тот же интерфейс, где сидит основной, в моём случае это ether5, то дополнительный IP начинает пинговаться

А если на loopback?

А если на loopback?

Сейчас ещё раз попробую, но первый раз не работало

А если на loopback?

Зачем это все? Есть простое решение. Человек просит чтобы ему на реальники можно было достучаться по порту 443. Это реализуется легко как портфорвард.