Назад | Перейти на главную страницу

Виртуализированный pfSense 2.0.1 влияет на подключение хоста Hyper-V? арп?

Установка

Я установил pfSense 2.0.1 (образ 64bit-amd) в качестве хоста в Hyper-V. Как описано в других блогах, мне пришлось выполнить «ifconfig down deX», «ifconfig up deX», чтобы запустить сеть.

Сервер (HP под управлением Windows 2008 R2) оснащен двумя физическими сетевыми адаптерами.

В Hyper-V определены следующие виртуальные сети:

В своей настройке я использую pfSense в качестве брандмауэра с выходом в Интернет для пары виртуальных машин (серверов Windows), также работающих на одном хосте Hyper-V.

Ящики Windows используют pfSense в качестве шлюза по умолчанию, и я успешно загрузил обновления Windows на все виртуальные машины через брандмауэр pfSense - работает без сбоев.

Для перенаправления входящих служб pfSense настроен с 1-1 NAT для сопоставления IP-адресов интернет-провайдеров с внутренними адресами 172.16.0.0/16 в ящиках Windows.

Эта проблема

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

  1. IP-адрес управления перемещен с порта 1 на порт 2. Это изменение было успешно проверено повторным подключением RDP через час к новому интерфейсу (порт 2, как описано выше).

  2. Сделал некоторые настройки виртуальных IP-адресов в pfSense (необходимые для NAT 1-1).

Через несколько минут связь с машиной была потеряна.

Что меня озадачивает, так это то, что сетевое соединение управления (порт 2) не должно затрагиваться Hyper-V, поскольку оно не интегрировано с Hyper-V. Однако, похоже, есть распространение ошибки из pfSense (с использованием NIC на порту 1).

Ранее сегодня у нас была аналогичная проблема при использовании только одной сетевой карты (порт 1 совместно используется Hyper-V / pfSense и хостом). Проблема, с которой мы столкнулись, заключалась в том, что когда pfSense был остановлен, мы могли проверить связь с хостом, а когда он был запущен снова, проверка связи перестала работать (нет конфликта IP, что мы знаем).

PfSense устанавливается из ISO, и «подмена MAC-адреса» по умолчанию отключена.

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

Любые комментарии по этому поводу очень ценятся.

/ Дж

Вы проверяли программу просмотра событий на W2008R2?

Возможно, из-за максимального количества TCP-соединений, разрешенных Windows: https://technet.microsoft.com/en-us/library/cc759700%28WS.10%29.aspx

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

Это больше похоже на проблему маршрутизации между pfSense и другими устройствами ...

Если вы используете виртуальные машины за pFSense в качестве брандмауэра, однако они вам нужны в другой подсети, чем ПК в локальной сети. Возможно, вам придется включить дополнительный интерфейс на pfSense (скажем, LAN2). Затем сопоставьте его на хосте виртуальной машины с частным VSwitch, которое используют другие виртуальные машины .. Или даже отметьте трафик в vSwitch и выделите для него отдельный vlan.

Мне приходилось делать это много раз на VMWare. Также для ваших 1: 1 вам, возможно, придется добавить статическое отображение сетевых маршрутов в качестве примера. Я видел, как pfSe nse испортил маршрутизацию.

Таким образом у вас есть ..

IINTERNET -> Wan0 -> pFSense -> ПК LAN1 ..

                  pfSense -->LAN2 Virtual Machines.

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

Надеюсь, это поможет, ура ...