OpenVPN Access Server – программный пакет, отличающейся от OpenVPN простотой настройки через удобный веб интерфейс и тем, что готов к работе практически сразу после установки. Об установке и поверхностной настройке я уже писала ранее. Сейчас же я хочу уделить внимание портам.

Ряд служб, запущенных на стороне пользователя, нередко требуют наличия открытых портов для корректной работы. Такие приложения, как P2P клиенты, игры с режимом мультиплеера, где инициатор сессии так же выступает в роли сервера, к которому присоединяются другие игроки, и прочие – все они требуют открытия определённых портов на компьютере пользователя для входящих соединений.

В «повседневности» перенаправлением запросов на порты занимается роутер или модем, с помощью UPnP. Но в моём случае, например, между мной и точкой выхода в Интернет в общей сложности три NATa и два программных фаервола. Другими словами, входящие соединения – проблема. Решается эта проблема поднятием тоннеля между ПК и точкой выхода. В таком случае трафик минует все эти узлы одним шифрованным потоком и «разбирается» только на моём компьютере и на стороне точки выхода, где поднята OpenVPN. Так же публичные сети и множество домовых сетей нередко блокируют все входящие соединения, по той простой причине, что все клиенты сети выходят в Интернет с одного внешнего IP, при этом технологии типа UPnP этими сетями не поддерживаются. Плюс ко всему, публичные Wi-Fi сети просто не безопасны. Другими словами, использование VPN может быть оправдано многими факторами: от паранойи и реальной цензуры внутри страны, до просто желания контролировать свой трафик лично, не публикуя весь расклад провайдеру и прочим заинтересованным лицам.

Итак, настраиваем OpenVPN Access Server. В панели управления, в секции «VPN Mode» настраиваем режим работы нашего сервера. OpenVPN Access Server может работать в двух режимах. «Layer 2» (ethernet bridging) и «Layer 3» (routing/NAT). Оба режима имеют как плюсы, так и минусы. В контексте рассматриваемой ситуации, более предпочтительным может быть вариант «Layer 2». Он более простой с минимумом настроек, при этом всем клиентам сети будут присваиваться локальные IP адреса реально существующей локальной сети на физическом интерфейсе. Если внешний интерфейс у нас eth0, то локальный как правило eth1. То есть сервер подключен к локальной сети с диапазоном IP адресов, например 10.10.1.0/24. В этой ситуации клиентам сети будут присваиваться адреса типа 10.10.1.2, 10.10.1.3, 10.10.1.4 и так далее. В этом случае никаких дополнительных настроек не требуется и UPnP будет перенаправлять входящие соединения на клиентские компьютеры. Несомненным минусом подобного режима является то, что все это будет работать преимущественно на Windows. То есть клиентский компьютер должен быть под управлением Windows. Вы не сможете подключиться к такой сети с планшета на Android и прочих устройств. Главным же минусом является тот факт, что на стороне сервера должна быть эта локальная сеть как таковая, при этом в ней должна работать технология UPnP, а адреса должны назначаться DHCP сервером. Если всё это вам не подходит, то остаётся вариант с NAT (режим «Layer 3»). Его мы и рассмотрим подробнее.

В разделе «VPN Settings» особенные настройки не требуются. В моём случае настройки выглядят как на скриншоте, но настройки «Static IP Address Network» не имеют отношения к нашей задаче. В моём случае это диапазон локальных IP, которые могут быть назначены определённым клиентам как статичные. В этом нет необходимости и клиентам могут назначаются IP адреса из диапазона 172.27.232.0/20 (что является диапазоном по умолчанию для OpenVPN Access Server), при этом всё будет работать.

Переходим в раздел «User Permissions» и настраиваем права отдельно взятого пользователя. Открывать порты мы будем с помощью DMZ.

Демилитаризованная зона в OpenVPN Access Server реализована достаточно грамотно, по сравнению с рядом бытовых роутеров, где на машину в DMZ перенаправляются все входящие запросы ко всем портам, при этом IP адрес такой машины должен быть статичным. В Access Server всё иначе. Запросы перенаправляются не на IP, а на клиента (IP клиента при этом может быть динамичным) и не все входящие запросы, а запросы, адресованные на определённые порты, по определённым протоколам. Синтаксис следующий: внешний_ip_сервера:протокол/порт. Например, p2p клиент «Ace Stream HD» на моём ПК использует порт 48621 по tcp и по udp. Стало быть, будет две записи подобного вида:

ххх.ххх.хх.хх:tcp/48621
ххх.ххх.хх.хх:udp/48621

Для платформы Steam - ххх.ххх.хх.хх:udp/27000-27050 и ххх.ххх.хх.хх:tcp/27015. И так далее.

Со Steam стоит проявить осторожность. VPN у них ассоциируется исключительно с попыткой обхода региональных ограничений и ценовой политики, при которой в связи со стремительным падением рубля, на пример, игры в рублёвой зоне стоят в среднем в два-три раза дешевле, чем в долларовой зоне. А в долларовой зоне игры дешевле, чем в зоне евро. Больше всех не повезло Аргентине, где за эквивалент в 80 долларов США можно получить то же самое, что в самих США будет стоить долларов 50, а в России рублей 800-900. Так или иначе, но при попытке это обойти и в случае, если вас поймают, ваш аккаунт гарантированно окажется в пожизненном бане, со всеми вытекающими последствиями. Однако, в свете очередного перла российских властей, изменится либо ценовая политика Valve в России, либо их отношение к VPN, либо и то и другое. Первый вариант более вероятен. Хотя подобное случалось, пожалуй, со всеми международными сервисами, представленными в России, но пока никто дверью не хлопнул. И по поводу DMZ на сайте поддержки написано, что система работать не будет. Но в случае с OpenVPN Access Server всё как бы работает. По крайней мере я не сталкивалась с проблемами соединения и Steam работает как задумано, вроде бы. Подробнее о портах, используемых в Steam, можно ознакомиться на сайте поддержки.

В остальном же, решение, основанное на DMZ в OpenVPN Access Server выглядит практически идеальным. Минусом является тот факт, что вы не можете открыть один и тот же порт для нескольких клиентов. Даже если онлайн находится только один из них. Если вы открыли порты Steam для определённого клиента, то только он и сможет их использовать.

В настройке «iptables» же на стороне сервера необходимости нет, даже если вы используете какую-либо стороннюю утилиту для управления фаерволом, типа «UFW». Access Server сам прописывает все необходимые правила iptables «на лету». Что означает, что правило активно лишь тогда, когда клиент онлайн. Если вы открыли ряд портов для определённого клиента, то «дозвониться» до этих портов можно лишь тогда, когда клиент подключён к сети. Если клиент офлайн, то и порты закрыты. Данный факт является несомненным плюсом в плане безопасности.

Для проверки портов на стороне клиентского ПК можно использовать программу «PortForward Network Utilities». В триальной версии она пожизненно бесплатная, хотя и нагружена рекламой, при этом урезанная. Но для проверки портов её вполне достаточно.

Как видно по скриншоту, у меня открыт udp порт 27025. При этом, как я сказала ранее, между мной и выходом в Интернет три NATa и два фаервола, если считать iptables на стороне Access Сервера и BitDefender на ПК. Если я отключусь от Access Server, то порт будет закрыт. И не важно с какой стороны его прозванивать.