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

Настройка pfSense OpenVPN в Azure

У меня есть небольшая сеть в Azure, к которой мне нужно предоставить доступ. Поскольку большинство людей в моем офисе используют Macbook, шлюз Microsoft VPN не будет работать.

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

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

Однако я не могу подключиться к серверу OpenVPN, чтобы установить соединение. На экране Open VPN connect я получаю следующее:

Wed Aug 31 15:49:00 2016 TCP: connect to [AF_INET]nnn.nnn.nnn.nnn:1194 failed, will try again in 5 seconds: Connection timed out (WSAETIMEDOUT)

У меня есть:

Проверено, что nnn.nnn.nnn.nnn является общедоступным IP-адресом виртуальной машины pfSense.
SSH подключился к виртуальной машине и убедился, что она прослушивает порт 1194 USER COMMAND PID FD PROTO LOCAL ADDRESS FOREIGN ADDRESS root openvpn 3403 6 tcp4 *:1194 *:* root nginx 23708 6 tcp4 *:443 *:* root nginx 23708 8 tcp4 *:80 *:* root sshd 13231 5 tcp4 *:22 *:*
Проверил группу сетевой безопасности для подсети виртуальной машины. Подтверждено, что он позволяет любому протоколу, любому источнику проходить через 1194
Проверил группу сетевой безопасности для сетевого интерфейса виртуальной машины. Подтверждено, что он установлен на «Нет»
Проверено, что я могу локально подключиться к порту 1194
Проверено, что я могу удаленно подключиться к порту 443 (помните, что я могу подключиться к веб-серверу виртуальной машины)
С консоли AppServices (настроено подключение к VNET) я могу подключиться к 80 и 443, но не к 1194 (время ожидания подключения).
Я не вижу в журналах pfSense никаких указаний на попытку подключения.
Запуск pfTop, когда SSH подключен к виртуальной машине, показывает попытки подключения для 80 и 443, но не для 1194.

Я считаю, что что-то в моей настройке виртуальной сети блокирует трафик на 1194, но я не уверен, где еще проверить.

Попробуйте подключиться к TCP 1194 локально. Этот тест позволит избежать влияния межсетевого экрана.

Если соединение не удается, это говорит о том, что на стороне сервера что-то не так.

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

Если адаптер получает пакеты от клиента, это означает, что что-то на сервере блокирует соединение. Наиболее частая причина - неправильно настроенный брандмауэр. (Iptables)

Если адаптер не получает пакеты, вам следует дважды проверить NSG. Или попробуйте их воссоздать. Если проблема не устранена, и вы уверены в правилах для входящих подключений NSG. Затем вам может потребоваться открыть билет с поддержкой Azure, чтобы они могли выполнить захват сети на уровне хоста, чтобы узнать, что отбрасывает пакеты.

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

Когда вы настраиваете OpenVPN для подключения через TCP, он не обновляет правило брандмауэра pfSense, которое допускает трафик на 1194. Это правило установлено на UDP. Изменение правила, разрешающего TCP, устраняет проблему.

Полезная информация

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

Имея эту информацию, вы можете подключиться по ssh к ящику и получить красивое маленькое консольное меню, обеспечивающее root-доступ.

С этой корневой консоли вы можете выключать и включать фильтр пакетов:

pfctl -d <disables>
pfctl -e <enables>

Временное отключение фильтра пакетов позволило мне исключить все, что связано с Azure, как источник моей проблемы.