странные проблемы с NAT с pfSense на бродячую виртуальную машину

Вот это меня смутило:

У меня есть брандмауэр pfSense (назовем его пфс) и за ним несколько серверов. Я без проблем подключаю несколько служб с моего общедоступного IP-адреса к разным серверам в локальной сети.

На одном из серверов (назовем его с1) я бегу бродяга (с либвирт) ВМ (назовем это v1) с общественный настроена сеть, которая получает IP 192.168.1.159 с помощью пфсDHCP-сервер.

Теперь я настраиваю простой NAT на пфс получить доступ с1SSH, скажем <wan>:6622 -> с1:22 и доступ к нему на mydomain.com:6622. Без проблем.

я также могу получить доступ v1:22 (или эквивалент 192.168.1.159:22) с действительным пользователем ssh из локальной сети без проблем.

Теперь я добавляю простой NAT на пфс, сказать <wan>:6722 -> v1:22. Сейчас пытаюсь получить доступ mydomain.com:6722 не работай?!

Цель состоит в том, чтобы добавить еще «еще один уровень»: запуск контейнеров с общедоступными портами, например. --опубликовать 9980:80 на v1 и получить к ним доступ, например. v1:9980 и из mydomain.com:9980 с включенным соответствующим NAT пфс нравиться <wan>:9980 -> v1:9980. Из локальной сети это также работает, как и ожидалось (т.е. я могу получить доступ v1:9980 из локальной сети), а NAT через пфс не является.

У меня аналогичные настройки работают в одной сети на разных машинах без проблем. У меня даже есть другой (небродячий, но тоже либвирт) ВМ включена с1 к которому я могу подключиться по ssh через NAT через мой общедоступный IP-адрес. Но почему-то вышеуказанное не работает с бродяга машина, и я действительно в недоумении, что может быть причиной этой проблемы. (FWIW у меня есть net.ipv4.форвард включено v1).

РЕДАКТИРОВАТЬ:

Я стал на шаг ближе: если я уничтожу первую существующую сетевую карту бродяга виртуальная машина, использующая вирт-менеджери установите для второй виртуальной машины значение rtl8139 вместо виртуозно (а затем перезапустить), я теряю бродячий ssh возможность, но NAT тогда работает. Таким образом, возникает вопрос: как настроить через бродяга обеспечение такое, что у нас похожий конфиг, я полагаю, это означает, что публичная сеть должна быть на интерфейсе по умолчанию?

Решение:

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

(Более надежный) вариант концепции настройки маршрутов по умолчанию принес решение. я использую доступный provisioner, где я выполняю следующее (в гостевой системе с помощью playbook):

  - имя: удалить неправильный маршрут по умолчанию на eth0 (снова)
    оболочка: |
      eval $(route -n | awk '$0~/[.0]{4}/ && $3~/[.0]{4}/ && $8~/eth0/ { printf "ip route del default via %s dev % с; ",$3,$8 }')

(интересно, что его нужно выполнить дважды (или через некоторое время?), возможно, потому, что сеть не заработала полностью, когда запустился скрипт предоставления?)

Это удаляет маршрут по умолчанию на eth0 ( общедоступная_сеть будет автоматически настроен только на эт1 к бродяга) и заставляет внешние подключения работать должным образом. Предположительно (предполагаю здесь) это связано с тем, что ответы на входящие запросы NAT направляются на брандмауэр через маршрут по умолчанию на eth0 по умолчанию (что по бродяга по умолчанию имеет приоритет), что сбивает с толку микропрограмму NAT, поскольку она эт1. Итак, удаление eth0 по умолчанию отвечает на внешние запросы на том же интерфейсе, на который они пришли.