Как настроить firewall для vpn

Control Panel (Панель управления) > Network and Internet (Сеть и Интернет) > Network and Sharing Center (Центр управления сетями и общим доступом).

Сетевые подключения (Wi-Fi) нужно указывать в профилях Work (Рабочая сеть) или Home (Домашняя сеть) для того, чтобы была правильная настройка ограничений.

Запускаем cmd.exe и выбираем ping 8.8.8.8, чтобы проверить правильную настройку.

Доступ в сеть должен работать именно при соединении OpenVPN.

ПРАВИЛО ДЛЯ РАЗРЕШЕНИЯ DNS ЗАПРОСОВ

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

Для этого зайдите в Outbound rules (Правила для исходящих подключений), выберите Core Networking (Основная сеть) – DNS (UDP-Out), вызовите контекстное меню, нажав правую кнопку мыши, и выберите Disable Rule (Отключить правило).

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

После того, как вы отключите правило Core Networking (Основная сеть) – DNS (UDP-Out) соединение с VPN-сервером по хостовому имени станет невозможным. Однако если конфигурационный файл предоставляет возможность подключения по IP-адресу, то соединение с VPN будет совершено после небольшой паузы в пару секунд.

Если у вас остались вопросы – смело задавайте их нашим специалистам и мы, в максимально короткий срок, постараемся вам помочь.

VidVPN – Включил и Доволен!

Источник

Как настроить Firewall для VPN-а на сервере с двумя IP

Я наконец-то завёл себе сервер. На нем разместил сайт своей «компании», а по соседству решил поднять VPN. Для этого был заказан второй IP. На первом у меня будет web, mail, ssh а с второго будет ходить VPN трафик. Задумка простая, но хорошего описания такой конфигурации я так и не нашел. Под катом, я покажу как настроить Shorewall чтобы VPN трафик шел только в интернет, и не мог свободно проходить на соседний IP.

В этом посте я хочу сделать фокус не на установку всех программ, это было описано много раз в том числе и на хабре, а на настройку firewall-a для ситуации когда все сетевые интерфейсы у нас на одной карте. Для управления firewall-ом я буду использовать пакет Shorewall. На сайте у shorewall-a довольно много документации, но она описывает в основом конфигурации с разделными сетевыми картами, и подсетями лежащими за ними.

Давайте сперва посмотрим на ifconfig. Там мы видим два наших IP-шника, «1.1.1.1» и «2.2.2.2». Они оба идут напрямую в интернет. Сейчас они «близнецы», то есть если какой-нибудь сервис крутится на первом, он будет виден и на втором IP.

Давайте это дело прикроем, так чтобы 1.1.1.1 пропускал на web, email, ssh, а 2.2.2.2 слушал vpn. Вот такая конфигурация:

Это стандартная конфигурация, которая пропускает весь трафик с нашего VPS-a в интернет, а назад не пускает ничего, кроме того что прописано в rules. Под зоной $FW, подразумеваются оба IP, так как оба являются частью eth0 (не смотря на то что у 2.2.2.2 есть своё имя eth0:0). Для уточнения используются кострукции типа: $FW:[ip]. Вроде всё нормально. Тогда, запускаем VPN сервер, и смотрим ifconfig. Помимо того что там уже было, появился новый interface tun0:

заметьте, что интерфейс tun0 не является «близнецом» с eth0, а представляет из себя более полноценный интефейс. За этой подсетью будут сидеть VPN клиенты. Давайте подсоединимся прямо сеичас. На другом компе: проходим авторизацию, соеденение установлено, идем в терминал и пробуем подсоединится хотя бы нашему vpn gateway (10.8.0.1) чтобы почитать почту, можно пинговать если пинги принимаются (см. /etc/sysctl.conf).

Наша попытка зайти на mail сервер была отвергнута, из за того что, не являсь «близнецом» eth0, tun0 не можем говорить с eth0 (и eth0:0) из за правила:

в конце /etc/shorewall/policy. Пока все правильно. Тогда добавим tun0 в shorewall.
Новая конфигурация:

Что изменилось? Мы создали зону под именем vpn4 которая соответствует интерфейсу tun0. Мы декларировали vpn4 как IPv4. Мы разрешили трафику из tun0 доходить до firewall-а, и до интернета (eth0/net4). Как ни странно, нельзя разрешить только до firewall-a, а дальше по существующему правилу $fw -> net4. Надо добавить обе строки. И последнее что нам надо для полноценного выхода в интернет, это SNAT (source address translation, когда подменяется адрес отправителя на адрес смотрящии в интернет, в нашем случае 2.2.2.2). Создаем файл masq и требуем там замены всех адресов 10.8.0.х на 2.2.2.2 при выходе из eth0 (и eth0:0).

Пробуем… Всё работает! Даже слишком… с адресом из 10.8.0.х можно заходить на 1.1.1.1:1194, чего мы никак не хотим. Мы хотели чтобы vpn трафик сперва выходил в интернет а потом бился назад через firewall. Вместо этого мы имеем vpn клиента который смотрит на наш сервер видом сзади. Почему? Потому что когда мы разрешили коммуникации типа:

мы не уточнили на какой именно IP, так как под $FW их два (1.1.1.1 и 2.2.2.2). Ну ладно, давайте пропишем. Ан-нет, синтаксис типа: $FW:[ip] в файле policy не принемается. На этом моменте я перепробовал много всего и почти бросил затею и оставил как есть. Хотя до конца пути было очень мало. Итак, озарение: все что прописывается в policy можно точно также прописать в rules, а в rules мы можем указывать конкретные IP на firewall-e. Давайте перепишем, последняя конфигурация:

Что мы сделали: убрали старые разрешения из policy, и добавили разрешения в rules. Мы разрешаем весь трафик из vpn в интернет, и выборочно разрешаем трафик непосредственно на 1.1.1.1. А через интернет заходы на 1.1.1.1 послать нельзя? Нет, как бы нам ни хотелось они будут идти внутри сервера, поетому лучшее что мы можем, это продублировать правила для интернета для трафика vpn -> 1.1.1.1. А как же трафик на 2.2.2.2? Этот трафик непосредвенно и есть vpn трафик, и он не может приходить изнутри (это обсепечивается route-ом на клиентской машине). В других словах, клиент vpn-a никогда не пришлет трафик по направлению 10.8.0.1(vpn4) -> 2.2.2.2($fw:2.2.2.2).

Ну вот в принципе и все. Теперь мы можем спокойно браузить с «рабочего» VPN-a без использования IP-шника ведущего на «компанейский» сайт, и не боятся за обход firewall-a обычными vpn юзерами.

Источник

Удаленная работа или обзор VPN в Sophos XG Firewall

Всем привет! Данная статья будет посвящена обзору функционала VPN в продукте Sophos XG Firewall. В предыдущей статье мы разбирали, как получить бесплатно данное решение по защите домашней сети с полной лицензией. Сегодня мы поговорим о функционале VPN который встроен в Sophos XG. Я постараюсь рассказать, что умеет данный продукт, а также приведу примеры настройки IPSec Site-to-Site VPN и пользовательского SSL VPN. Итак, приступим к обзору.

Первым делом посмотрим на таблицу лицензирования:

Более подробно о том, как лицензируется Sophos XG Firewall можно прочитать тут:
Ссылка
Но в данной статье нас будут интересовать только те пункты, которые выделены красным.

Основной функционал VPN входит в базовую лицензию и приобретается только один раз. Это пожизненная лицензия и она не требует продления. В модуль Base VPN Options входит:

• SSL VPN
• IPSec VPN

Remote Access (клиентский VPN):

• SSL VPN
• IPsec Clientless VPN (с бесплатным пользовательским приложением)
• L2TP
• PPTP

Как видим, поддерживаются все популярные протоколы и типы VPN соединений.

Также, в Sophos XG Firewall есть еще два типа VPN соединений, которые не включены в базовую подписку. Это RED VPN и HTML5 VPN. Данные VPN соединения входят в подписку Network Protection, а это значит, чтобы использовать данные типы необходимо иметь активную подписку, в которую, также входит и функционал защиты сети – IPS и ATP модули.

RED VPN — это проприетарный L2 VPN от компании Sophos. Данный тип VPN соединения имеет ряд преимуществ по сравнению с Site-to-site SSL или IPSec при настройке VPN между двумя XG. В отличии от IPSec, RED туннель создает виртуальный интерфейс на обоих концах туннеля, что помогает при траблшуте проблем, и в отличии от SSL, данный виртуальный интерфейс полностью настраиваемый. Администратор имеет полный контроль над подсетью внутри RED туннеля, что позволяет проще решать проблемы маршрутизации и конфликты подсетей.

HTML5 VPN или Clientless VPN – Специфический тип VPN, позволяющий прокидывать сервисы через HTML5 прямо в браузере. Типы сервисов, которые можно настроить:

• RDP
• Telnet
• SSH
• VNC
• FTP
• FTPS
• SFTP
• SMB

Но стоит учесть, что данный тип VPN применяется, только, в особых случаях и рекомендуется, если есть возможность, использовать типы VPN из списков выше.

Практика

Разберем на практике, как настроить несколько из данных типов туннелей, а именно: Site-to-Site IPSec и SSL VPN Remote Access.

Site-to-Site IPSec VPN

Начнем с того, как настроить Site-to-Site IPSec VPN туннель между двумя Sophos XG Firewall. Под капотом используется strongSwan, что позволяет подключиться к любому маршрутизатору с поддержкой IPSec.

Можно использовать удобный и быстрый wizard настройки, но мы пойдем общим путем, чтобы на основе данной инструкции можно было совместить Sophos XG с любым оборудованием по IPSec.

Откроем окно настроек политик:

Как мы видим, существуют уже предустановленные настройки, но мы будем создавать свою.

Настроим параметры шифрования для первой и второй фазы и сохраним политику. По аналогии, делаем такие же действия на втором Sophos XG и переходим к настройке самого IPSec туннеля

Вводим название, режим работы и настраиваем параметры шифрования. Для примера будем использовать Preshared Key

и укажем локальные и удаленные подсети.

Наше соединение создано

По аналогии, делаем такие же настройки на втором Sophos XG, за исключением режима работы, там поставим Initiate the connection

Теперь у нас есть два настроенных туннеля. Далее, нам надо их активировать и запустить. Делается это очень просто, надо нажать на красный кружок под словом Active чтобы активировать и на красный кружок под Connection, чтобы запустить коннект.
Если мы видим такую картинку:

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

Отдельно хочу выделить, что можно из IPSec туннелей создавать Failover группы для отказоустойчивости:

Remote Access SSL VPN

Перейдем к Remote Access SSL VPN для пользователей. Под капотом крутится стандартный OpenVPN. Это позволяет пользователям подключаться через любой клиент, который поддерживает .ovpn конфигурационные файлы (например, стандартный клиент подключения).

Для начала, надо настроить политики OpenVPN сервера:

Указать транспорт для подключения, настроить порт, диапазон ip адресов для подключения удаленных пользователей

Также, можно указать настройки шифрования.

После настройки сервера, приступаем к настройке клиентских подключений.

Каждое правило подключения к SSL VPN создается для группы или для отдельного пользователя. У каждого пользователя может быть только одна политика подключения. По настройкам, из интересного, для каждого такого правила можно указать, как отдельных пользователей, кто будет использовать данную настройку или группу из AD, можно включить галочку, чтобы весь трафик заворачивался в VPN туннель или указать доступные для пользователей ip адреса, подсети или FQDN имена. На основе данных политик будет автоматически создан .ovpn профайл с настройками для клиента.

Используя пользовательский портал, пользователь может скачать как .ovpn файл с настройками для VPN клиента, так и установочный файл VPN клиента со встроенным файлом настроек подключения.

Заключение

В данной статье мы вкратце пробежались по функционалу VPN в продукте Sophos XG Firewall. Посмотрели, как можно настроить IPSec VPN и SSL VPN. Это далеко не полный список того, что умеет данное решение. В следующих статьях постараюсь сделать обзор на RED VPN и показать, как это выглядит в самом решении.

Источник