Как организовать доступ к виртуальным машинам за nat из другой сети без использования port forward?

[deity]

Микротик bridge1:192.168.1.1/24, dhcp, один из внутренних хостов - 192.168.1.100. На нем vmware nat 192.168.5.1/24, dhcp 192.168.5.128-254. Две вирутуалки за этим натом 192.168.5.128, 192.168.5.129.
Какими средствами правильно будет сделать уд доступ к этим виртуалкам из пула bridge1? Я поискал возможность добавления static route и vlan на маршрутизаторе, добавления интерфейса 192.168.5.1, но ни по одному из этих вариантов я не могу самостоятельно однозначно сориентироваться. Спасибо!

В двух словах:
Вообще, вкратце, просто нужно, чтобы зона 192.168.5.1/24, находящаяся за клиентом 192.168.1.100, была доступна всем клиентам из 192.168.1.1/24

[pingz]

add action=src-nat chain=srcnat dst-address=192.168.5.0/24 to-addresses=192.168.1.100

 

[VolanD666]

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

Микротик bridge1:192.168.1.1/24, dhcp, один из внутренних хостов - 192.168.1.100. На нем vmware nat 192.168.5.1/24, dhcp 192.168.5.128-254. Две вирутуалки за этим натом 192.168.5.128, 192.168.5.129.
Какими средствами правильно будет сделать уд доступ к этим виртуалкам из пула bridge1? Я поискал возможность добавления static route и vlan на маршрутизаторе, добавления интерфейса 192.168.5.1, но ни по одному из этих вариантов я не могу самостоятельно однозначно сориентироваться. Спасибо!

В двух словах:
Вообще, вкратце, просто нужно, чтобы зона 192.168.5.1/24, находящаяся за клиентом 192.168.1.100, была доступна всем клиентам из 192.168.1.1/24

Настройте маршрутизацию, зачем вам там нат?

[pingz]

@VolanD666  есть такая вещь, надо, зачем вникать? 

[nkusnetsov]

9 часов назад, pingz сказал:

add action=src-nat chain=srcnat dst-address=192.168.5.0/24 to-addresses=192.168.1.100

Вот это вообще, как по-вашему, по-наркомански работать должно?
 

 

11 часов назад, deity сказал:

В двух словах:
Вообще, вкратце, просто нужно, чтобы зона 192.168.5.1/24, находящаяся за клиентом 192.168.1.100, была доступна всем клиентам из 192.168.1.1/24

Можно на микротике прописать /ip route add dst-address=192.168.5.0/24 gateway=192.168.1.100
Тогда клиенты использующие микротик в качестве шлюза получат сообщение icmp-redirect. Если в фаерволах запретов нет,  и всякие "[name] internet security" не режут icmp-редиректы, подсеть 192.168.5.0/24 станет доступна из 192.168.1.0/24

[deity]

22 hours ago, nkusnetsov said:

/ip route add dst-address=192.168.5.0/24 gateway=192.168.1.100

Само по себе существование этого правила, как будто, ни на что не влияет. Трассировка с wlan1:192.168.1.101 обрывается на 192.168.1.1, встроенный сниффер видит, как icmp входят во wlan1, идут дальше в bridge1, все. между 1.101 и 1.100 трафик ходит ок. Может эту маршрутизацию нужно дополнить нат правилами? В другом месте как-то немногозначительно указали на технологию proxy-arp. Имеет ли какое-то отношение к ней моя текущая задача?

On 10/30/2018 at 6:40 AM, pingz said:

add action=src-nat chain=srcnat dst-address=192.168.5.0/24 to-addresses=192.168.1.100

 

Требуется доставать до адресов, находящихся за 1.100, а не редиректить трафик на 1.100 при обращении к пулу 192.168.5.0/24, что я, полагаю, подразумевает это правило

[EugeneTV]

Для чего нужен нат между двумя серыми сетями?

[nkusnetsov]

3 часа назад, deity сказал:

Само по себе существование этого правила, как будто, ни на что не влияет.

Печально. В нормальных системах роутер отвечает пакетом icmp-redirect (типа, "чувак, это не ко мне, путь в 192.168.5.0/24 есть через 192.168.1.100!"), зост-отправитель теряет первый icmp-echo пакет, но остальные перенаправляет на 192.168.1.100 и пинг идёт со второго пакета.
Искать тут надо wireshark-ом. Проблем возможно несколько:
1) основной шлюз не шлет icmp-redirect
2) отправитель убивает или игнорит полученный icmp-redirect
3) на 192.168.1.100 убиваются пакеты адресованые сети 192.168.5.0/24

П.3 можно проверить принудительно прописав на клиенте 192.168.1.101 маршрут в сеть 192.168.5.0/24 через 192.168.1.100. Для винды как-то так "route add 192.168.5.0 mask 255.255.255.0 192.168.1.100"
 

[deity]

5 hours ago, nkusnetsov said:

Печально. В нормальных системах роутер отвечает пакетом icmp-redirect (типа, "чувак, это не ко мне, путь в 192.168.5.0/24 есть через 192.168.1.100!"), зост-отправитель теряет первый icmp-echo пакет, но остальные перенаправляет на 192.168.1.100 и пинг идёт со второго пакета.
Искать тут надо wireshark-ом. Проблем возможно несколько:
1) основной шлюз не шлет icmp-redirect
2) отправитель убивает или игнорит полученный icmp-redirect
3) на 192.168.1.100 убиваются пакеты адресованые сети 192.168.5.0/24

П.3 можно проверить принудительно прописав на клиенте 192.168.1.101 маршрут в сеть 192.168.5.0/24 через 192.168.1.100. Для винды как-то так "route add 192.168.5.0 mask 255.255.255.0 192.168.1.100"
 

Честно говоря, после добавления правила и прогонкой встроенным сниффером на микротике, у меня сложилось впечатление, что пакеты вообще не добивают до хоста 1.100, ошибочное)

После вашего развернутого изложения, касательно icmp-redirect я решил пройтись по вашим пунктам. Включил акулу на 1.100, взял в руки виндовый ноут с акулой вместо андроид 1.101 и с него уже без добавления статик маршрута пытался пингануть. В итоге: приходят icmp-redirects на пингующий хост 1.101, на gw 1.100 обнаруживаются icmp запросы, приходящие от 1.101 и адресованные 192.168.5.128. Не приходят ответы от 5.128, при прослушивании интерфейса 192.168.5.1 никаких icmp внутрь этой сети не обнаруживается. Винда, фаервол выключен, по сути, это уже не относится к микротику, но все же кажется, что я уже где-то близко, не так ли?

 

route print:

IPv4 Route Table
===========================================================================
Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0      192.168.1.1     192.168.1.100     35
        127.0.0.0        255.0.0.0         On-link         127.0.0.1     331
        127.0.0.1  255.255.255.255         On-link         127.0.0.1     331
  127.255.255.255  255.255.255.255         On-link         127.0.0.1     331
      192.168.1.0    255.255.255.0         On-link      192.168.1.100    291
    192.168.1.100  255.255.255.255         On-link      192.168.1.100    291
    192.168.1.255  255.255.255.255         On-link      192.168.1.100    291
      192.168.5.0    255.255.255.0         On-link      192.168.5.1      291
      192.168.5.1  255.255.255.255         On-link      192.168.5.1      291
    192.168.5.255  255.255.255.255         On-link      192.168.5.1      291
        224.0.0.0        240.0.0.0         On-link         127.0.0.1     331
        224.0.0.0        240.0.0.0         On-link      192.168.5.1      291
        224.0.0.0        240.0.0.0         On-link      192.168.1.100    291
  255.255.255.255  255.255.255.255         On-link         127.0.0.1     331
  255.255.255.255  255.255.255.255         On-link      192.168.5.1      291
  255.255.255.255  255.255.255.255         On-link      192.168.1.100    291
===========================================================================

Edited October 31, 2018 by deity

[maxkst]

@deity Не только я задаюсь вопросом. Зачем тут нат вам? Просто любопытно

[nkusnetsov]

В 01.11.2018 в 04:35, deity сказал:

Не приходят ответы от 5.128

Надо искать на линке .5.1 - .5.128.
Nat там действительно ни к чему, если прописаны маршруты на основном роутере.

 

 

В 01.11.2018 в 04:35, deity сказал:

прослушивании интерфейса 192.168.5.1 никаких icmp внутрь этой сети не обнаруживается

Возможно , всё же хост с vmware тупо режет пакеты адресованые nat-сети. см.п.3 
"3) на 192.168.1.100 убиваются пакеты адресованые сети 192.168.5.0/24"

[deity]

21 hours ago, maxkst said:

@deity Не только я задаюсь вопросом. Зачем тут нат вам? Просто любопытно

Все по той же причине.. из любопытства :)

1 hour ago, nkusnetsov said:

Надо искать на линке .5.1 - .5.128.
Nat там действительно ни к чему, если прописаны маршруты на основном роутере.

 

 

Возможно , всё же хост с vmware тупо режет пакеты адресованые nat-сети. см.п.3 
"3) на 192.168.1.100 убиваются пакеты адресованые сети 192.168.5.0/24"

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

[deity]

On 11/2/2018 at 2:53 PM, deity said:

Проблема, видимо, в маршрутизации или какой-то деактивированной опции операционки

оставалось только разрешить маршрутизацию пакетов через хост 1.100 и прописать обратный маршрут на хостах 5.128 и 5.129

192.168.1.0/24 via 192.168.5.1
192.168.1.100/32 via 192.168.5.2

@nkusnetsov безгранично вам благодарен за отзывчивость в поиске решения :)

[maxkst]

Вам все еще нужен нат?