Перейти к контенту

Рекомендуемые сообщения

Здравствуйте, появилось необходимость использовать nat, но вот настроить не получается.

Есть координатор с двумя интерфейсами 192.168.0.107 и 85.143.200.7, тунель к серверу 172.17.3.78 , необходимо наладить двухсторонний доступ к серверу 10.128.66.207 находящемуся за своим координатором. Нужна именно трансляция по определенному порту , чтобы на удаленном сервере был доступен веб интерфейс сервера по адресу http:85.143.200.7:56789 к примеру.

После поиска в инете пришел к такому 

[nat]

rule= num 2 proto any from anyip to 85.143.200.7   change src=172.17.3.78 

[forward]

rule=num 1 proto any from 10.128.66.207 to 172.17.3.78 pass

 

Но как прописать трансляцию по определенному порту я так и не понял

Буду очень признателен , если кто-нибудь подскажет что же делать в этом случае

Поделиться этим сообщением


Ссылка на сообщение
Поделиться на других сайтах

10.128.66.207 отсносится к координатору как? открытый, защищенный, туннелируемый?

Какая платформа и версия?

Поделиться этим сообщением


Ссылка на сообщение
Поделиться на других сайтах
2 часа назад, azz сказал:

10.128.66.207 отсносится к координатору как? открытый, защищенный, туннелируемый?

Какая платформа и версия?

hw1000 ( Linux 2.6.32 i686 ) ПО 3.2

10.128.66.207 туннелируемый 

Поделиться этим сообщением


Ссылка на сообщение
Поделиться на других сайтах

Нужно подменять не адрес источника, а адрес назначения. change dst

Поделиться этим сообщением


Ссылка на сообщение
Поделиться на других сайтах

Я бы для начала обновился на одну из версий 4.2 ...

Поделиться этим сообщением


Ссылка на сообщение
Поделиться на других сайтах

Пока нет возможности обновить до 4.2
 

В ‎19‎.‎05‎.‎2018 в 00:16, KIV сказал:

Нужно подменять не адрес источника, а адрес назначения. change dst

Прописал так

[nat]

rule= num 2 proto tcp from anyip to 85.143.200.7:80   change dst=172.17.3.78:80

[forward]

rule=num 1 proto any from 10.128.66.207 to 172.17.3.78:80 pass

Вот так?  чувствую этого недостаточно потому что доступа так и нет, а что в этом случаю прописывать в маршрутах на 172.17.3.78 если основной шлюз на сервере поменять нельзя?

Поделиться этим сообщением


Ссылка на сообщение
Поделиться на других сайтах

Вот совсем не ясно, зачем натить туннелируемые адреса. 

Вы сами говорили что: 

В 18.05.2018 в 23:24, aa.con2014 сказал:

Есть координатор с двумя интерфейсами 192.168.0.107 и 85.143.200.7, тунель к серверу 172.17.3.78

и

В 19.05.2018 в 02:41, aa.con2014 сказал:

10.128.66.207 туннелируемый 

И вот это не ясно, если 

В 18.05.2018 в 23:24, aa.con2014 сказал:

тунель к серверу 172.17.3.78

то как на координаторе 2 интерфейса?

Может все же схему предоставите с указанием IP-адресов и промежуточного сетевого оборудования?? 

Поделиться этим сообщением


Ссылка на сообщение
Поделиться на других сайтах

Возможно, что в этой версии натирование адреса назначения для туннелируемого трафика работать не будет.

Поделиться этим сообщением


Ссылка на сообщение
Поделиться на других сайтах

Натирование трафика для туннелируемого адреса и в 4.2 не работает пока. 

Поделиться этим сообщением


Ссылка на сообщение
Поделиться на других сайтах

Спасибо за ответы, печально что трансляция не работает с туннелями, значит пойду по другому пути .

 

Поделиться этим сообщением


Ссылка на сообщение
Поделиться на других сайтах
В 5/19/2018 в 00:16, KIV сказал:

Нужно подменять не адрес источника, а адрес назначения. change dst

 Такая трансформация никогда  и не работала с туннелями и скорее всего никогда и не будет. Её смысл абсолютно непонятен. Или Вы обращаетесь на сам туннель или на координатор.

Вот для открытого трафика такой тип натирования допустим, но не для защищённого.

Поделиться этим сообщением


Ссылка на сообщение
Поделиться на других сайтах

Из вышесказанного, как осуществить схему которая сейчас работает на стороннем оборудовании.
Удаленные клиенты подключаются по vpn и используют для работы виртуальный адрес a.a.a.a который транслируется в b.b.b.b

Если перевести этих клиентов на hw1000, как реализовать доступ этих клиентов из защищено сети к адресу a.a.a.a который ДОЛЖЕН транслироваться в b.b.b.b, если тут говорят что это НЕ работает и кому-то кажется что "это и не нужно" ?!!!
Все клиенты ничего не знают про b.b.b.b
Все клиенты знают только a.a.a.a, менять этот адрес это большие затраты по времени.
Адрес b.b.b.b может меняться и это легко меняется в одной строчке нат трансляции на старом действующем фаерволе.

Поделиться этим сообщением


Ссылка на сообщение
Поделиться на других сайтах

Нарисуйте, пожалуйста схему. Удаленный север это что за сущность? Просто какой-то сервер, который будет ходить через Интернет на защищерный сервер? Или между ним и hw будет туннель. Давай вобщем схему, ничего непонятно.

Поделиться этим сообщением


Ссылка на сообщение
Поделиться на других сайтах

R.Sheyn, если про "Удаленный север это что за сущность?" вы у меня спрашиваете, то я не понял про что вы.

vipnet client --- internet ---- hw1000 ---- core ---- srv(b.b.b.b)

vipnet client ничего не знает про b.b.b.b и обращается на адрес a.a.a.a который прописан в разделе туннелирование на координаторе.

На координаторе должно работать (но не работает) правило  (NAT   @any   @any    >  a.a.a.a    Change: b.b.b.b)

 

Поделиться этим сообщением


Ссылка на сообщение
Поделиться на других сайтах
45 минут назад, P.Rost сказал:

R.Sheyn, если про "Удаленный север это что за сущность?" вы у меня спрашиваете, то я не понял про что вы.

vipnet client --- internet ---- hw1000 ---- core ---- srv(b.b.b.b)

vipnet client ничего не знает про b.b.b.b и обращается на адрес a.a.a.a который прописан в разделе туннелирование на координаторе.

На координаторе должно работать (но не работает) правило  (NAT   @any   @any    >  a.a.a.a    Change: b.b.b.b)

 

в первом сообщении было написано про удаленный сервер.

Смысл понятен, проверю, по моему делали такое.

Поделиться этим сообщением


Ссылка на сообщение
Поделиться на других сайтах
15 часов назад, R.Sheyn сказал:

по моему делали такое

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

Поделиться этим сообщением


Ссылка на сообщение
Поделиться на других сайтах
1 час назад, zero сказал:

Обращающийся на определенный защищенный ресурс должен быть уверен, что именно на него и попадает, а не на какой-то другой, который ему "подставили" натом.

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

Т.е. вариантов как применить "хакерский" метод полно.

Поделиться этим сообщением


Ссылка на сообщение
Поделиться на других сайтах
10 минут назад, R.Sheyn сказал:

Т.е. вариантов как применить "хакерский" метод полно.

Но не на самом СКЗИ. Кто там что на роутерах "мутит" разберутся сетевики с подачи безопасников.

Поделиться этим сообщением


Ссылка на сообщение
Поделиться на других сайтах

Проверил, не работает. Ну значит можно костыль использовать, поднять какой-нибудь роутер и делать порт форвардинг, как я писал выше.

Вообще было бы отлично, если бы это как-то было захардкожено, блокировалось бы просто с каким-нибудь событием, типа нельзя натировать dst для туннельного трафика. А сейчас координатор себя просто ведет неадекватно и все. Получил пакет, отнатил, а на следующий интерфейс не переложил, пакет погиб смертью храбрых где-то в недрах драйвера )

Поделиться этим сообщением


Ссылка на сообщение
Поделиться на других сайтах
53 минуты назад, R.Sheyn сказал:

типа нельзя натировать dst для туннельного трафика

  Доработка специального события для неподдерживаемого сценария вряд ли будет приоритетной.

Из все переписки не ясно, зачем трафик для туннеля направлять на другой ресурс? Балансировщик работает совершенно по другому, на прикладном уровне распределяя поступившие запросы, там никакого nat не нужно.

 Остаются soho-хакеры?

Поделиться этим сообщением


Ссылка на сообщение
Поделиться на других сайтах
21 минуту назад, zero сказал:

Доработка специального события для неподдерживаемого сценария вряд ли будет приоритетной.

Приоритетной или нет, конечно не мне решать, но крайне странно, что продукт позволяет настроить неподдерживаемый функционал, при этом еще и не алертить нигде, просто где-то внутри своей логики бесследно дропать такой трафик.

Зачем так делать инициатор написал, есть некий адрес, который распространен по продакшену, производить смену адреса достаточно энергрозатратно, наверняка связано с даунтаймом сервиса. 

21 минуту назад, zero сказал:

Балансировщик работает совершенно по другому, на прикладном уровне распределяя поступившие запросы, там никакого nat не нужно.

В смысле по другому? Распределять он действительно может основываясь на правилах прикладного уровня, но dnat он все равно выполняет, иначе как пакеты дойдут на бекэндов, более того и snat зачастую настраивается.

Логика абсолютно та же, пользователи обращаются на анонсируемый им адрес, а какие процессы происходят за балансировщиком, какая там адресация итд итп им неведомо. Куда администратор балансировщика пожелает, туда и направит.

С каких пор штатный функционал ната стал хакерством?)

Поделиться этим сообщением


Ссылка на сообщение
Поделиться на других сайтах
10 минут назад, R.Sheyn сказал:

крайне странно, что продукт позволяет настроить неподдерживаемый функционал, при этом еще и не алертить нигде, просто где-то внутри своей логики бесследно дропать такой трафик

  Нат настраивается отдельно, это функционал МЭ. В правиле Вы можете написать "натить трафик со всех адресов, который пришел на адрес координатора и перенаправлять на адрес такой-то". И для открытого трафика это правило должно и будет работать. Запретить тут что-то писать нельзя.

  Но перед натом еще нужно расшифровать трафик и принять решение, что с ним делать дальше. Видимо тут и заложена блокировка. Как сделать правильно её отображение или убрать саму блокировку, вопрос дискуссионный. Попробуем передать его экпертам.

 

20 минут назад, R.Sheyn сказал:

есть некий адрес, который распространен по продакшену, производить смену адреса достаточно энергрозатратно, наверняка связано с даунтаймом сервиса

Все равно это придётся сделать, так как описанный сценарий с натом не будет работать на координаторе. Вероятно, перед реализацией схемы стоило проверить ее работоспособность или уточнить в ТП, будет ли она работать.

21 минуту назад, R.Sheyn сказал:

С каких пор штатный функционал ната стал хакерством?)

Это СКЗИ, а не роутер. У продукта есть поддерживаемые сценари, а есть неподдерживаемые. В защищенной сети не поддерживаются многие сценарии натирования. Во многом это сделано осознанно, чтобы не было возможности компрометировать узлы и передаваемые им данные. Отправитель должен быть уверен, что его трафик получит именно тот узел, на который он направлен. Если разрешить любой нат, то администратор координатора сможет перенаправлять трафик на свой узел, модифицировать (снова занатив) его и доставлять на конечный узел, а затем проводить данные манипуляции и в обратную сторону.

  

 

Поделиться этим сообщением


Ссылка на сообщение
Поделиться на других сайтах

Если передадите, то будет хорошо, пусть хотя бы в журнале пакетов показывает "Мол нат туннельного трафика-блок". На мой взгляд, если какой-то функционал не поддерживается, то это должно иметь хоть какое-то отражение в недрах самого продукта, а не только в документации.

Поделиться этим сообщением


Ссылка на сообщение
Поделиться на других сайтах

Пожалуйста, авторизуйтесь, чтобы оставить комментарий

Вы сможете оставлять комментарии после авторизации



Войти

×

Важная информация

By using this site, you agree to our Условия использования.