NAT и Vipnet

[aa.con2014]

Здравствуйте, появилось необходимость использовать 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

 

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

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

[azz]

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

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

[aa.con2014]

2 часа назад, azz сказал:

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

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

hw1000 ( Linux 2.6.32 i686 ) ПО 3.2

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

[KIV]

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

[azz]

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

[aa.con2014]

Пока нет возможности обновить до 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 если основной шлюз на сервере поменять нельзя?

[Wild]

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

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

В 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-адресов и промежуточного сетевого оборудования?? 

[azz]

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

[Wild]

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

[aa.con2014]

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

 

[zero]

В 5/19/2018 в 00:16, KIV сказал:

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

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

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

[P.Rost]

Из вышесказанного, как осуществить схему которая сейчас работает на стороннем оборудовании.
Удаленные клиенты подключаются по 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 может меняться и это легко меняется в одной строчке нат трансляции на старом действующем фаерволе.

[R.Sheyn]

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

[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)

 

[R.Sheyn]

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)

 

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

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

[zero]

15 часов назад, R.Sheyn сказал:

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

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

[R.Sheyn]

1 час назад, zero сказал:

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

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

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

[zero]

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

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

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

[R.Sheyn]

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

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

[zero]

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

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

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

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

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

[R.Sheyn]

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

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

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

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

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

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

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

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

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

[zero]

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

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

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

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

 

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

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

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

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

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

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

  

 

[R.Sheyn]

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