странные проблемы с NAT при подключении pfSense к бродячей виртуальной машине
Этот меня смутил:
У меня есть брандмауэр pfSense (назовем егоpfs)и за ним несколько серверов. Я без проблем подключаю несколько служб с моего общедоступного IP-адреса к разным серверам в локальной сети.
На одном из серверов (назовем егоs1)Я запускаюvagrant(сlibvirt)ВМ (назовем егоv1)с настроенной публичной сетью, который получает IP 192.168.1.159через DHCP-сервер pfs.
Теперь я настраиваю простой NAT на pfsдля доступа к SSH s1, скажем <wan>:6622 -> s1:22, и получаю доступ к нему по mydomain.com:6622. Без проблем.
Я также могу получить доступ кv1:22(или эквивалентному192.168.1.159:22)с действительным пользователем ssh из локальной сети без проблем.
Теперь я добавляю простой NAT на pfs, скажем <wan>:6722 -> v1:22. Теперь попытка доступа кmydomain.com:6722не работает ?!
Цель состоит в том, чтобы добавить еще «еще один уровень»:запуска контейнеров с общедоступными портами, например. --publish 9980:80на v1и получить к ним доступ, например. v1:9980и из mydomain.com:9980с соответствующим NAT на pfs, например <wan>:9980 -> v1:9980. Из локальной сети это также работает как положено (т.е. Я могу получить доступ к v1:9980из локальной сети ), но через NAT через pfsнет.
У меня похожие установки работают в одной сети на разных машинах без проблем. У меня даже есть другая (не-бродячая, но такжеlibvirt)виртуальная машина на s1, к которой я могу подключиться по ssh через NAT через свой общедоступный IP-адрес. Но почему-то вышеперечисленное не работает с машиной vagrant, и я действительно не понимаю, что может быть причиной этой проблемы. (FWIW У меня включен net.ipv4.forwardнаv1).
РЕДАКТИРОВАТЬ:
Я стал на один шаг ближе:, если я уничтожу первую существующую сетевую карту vagrantВМ, используя virt-manager,и установите вторую виртуальную машину на rtl8139вместо virtio(, а затем перезапустите ), я теряю возможность vagrant ssh, но NAT затем работает. Таким образом, возникает вопрос :, как настроить через vagrantобеспечение таким образом, чтобы у нас была похожая конфигурация, я полагаю, это означает, что тогда общедоступная сеть должна быть на интерфейсе по умолчанию?
Решение:
Причина в том, что vagrantтребует (и, следовательно, настраивает) свой локальный интерфейс (частную сеть) в качестве основного, без стандартного метода для его переопределения. (Некоторая информация здесь, но бродячиелюди признают, что они сами запутались в этой теме...)
(более надежный) вариант концепции для настройки маршруты по умолчанию принесли решение. Я использую ansibleProvisioner, где я выполняю следующее (на госте, через Provisioning playbook):
- name: remove wrong default route on eth0 (again)
shell: |
eval $(route -n | awk '$0~/[.0]{4}/ && $3~/[.0]{4}/ && $8~/eth0/ { printf "ip route del default via %s dev %s; ",$3,$8 }')
(интересно, что его нужно выполнить дважды (или через некоторое время?), возможно потому что сеть не была полностью загружена, когда запустился скрипт предоставления?)
Это удаляет маршрут по умолчанию на eth0(public_networkбудет автоматически настроен только на eth1by vagrant) и заставляет внешние соединения работать должным образом. Предположительно (предположительно здесь) это связано с тем, что ответы на входящие NAT-запросы направляются на брандмауэр через маршрут по умолчанию на eth0по умолчанию (который по умолчанию vagrantимеет приоритет) , что сбивает с толку NAT FW, потому что он вошел в виртуальную машину eth1. Поэтому удаление eth0в качестве ответов по умолчанию на внешние запросы на том же интерфейсе, на который они пришли.