Настраиваем проброс портов в Windows при помощи командной строки и Portproxy

Необходимость проброса портов весьма часто встающая перед системным администратором задача. Обычно для этой цели используют службы маршрутизации и удаленного доступа (RRAS), но в ряде случаев использование данного инструмента избыточно. В тоже время немногие знают о такой службе как Portproxy, которая управляется из командной строки при помощи команд Netsh. Тем не менее данная служба позволяет справиться с поставленной задачей проще, быстрее и удобнее, чем инструменты графического интерфейса.

Онлайн-курс по устройству компьютерных сетей
На углубленном курсе "Архитектура современных компьютерных сетей" вы с нуля научитесь работать с Wireshark и «под микроскопом» изучите работу сетевых протоколов. На протяжении курса надо будет выполнить более пятидесяти лабораторных работ в Wireshark.

Часто можно услышать совершенно неверное утверждение, что в части сетевых настроек операционные системы Windows значительно уступают своим конкурентам (Linux и BSD). Отчасти такие суждения опираются на опыт администрирования стандартных ролей полностью игнорируя возможности командной строки.

Начиная с Windows Server 2003 в состав системы был в введена команда Netsh, которая позволяет гибко управлять сетевыми настройками компьютера. Обзор всех возможностей этой утилиты займет не одну статью, поэтому мы остановимся на командах Netsh для интерфейса Portproxy, позволяющих непосредственно решить нашу задачу.

Данный набор команд позволяет перенаправлять приходящие пакеты с IPv4 и IPv6 портов на любые IPv4 и IPv6 порты компьютера назначения в любых комбинациях. Единственное ограничение - portproxy может работать только с протоколом TCP, но в большинстве случаев этого достаточно.

Для добавления перенаправления используется команда add v4tov4 (если требуется перенаправление с IPv4 в IPv6 используйте v4tov6 и т.д.), полный синтаксис будет такой:

netsh interface portproxy add v4tov4 listenaddress=xxx.xxx.xxx.xxx listenport=nnn connectaddress=xxx.xxx.xxx.xxx connectport=nnn

где:

listenaddress - локальный адрес на котором принимаются соединения
listenport - локальный порт на котором принимаются соединения
connectaddress - удаленный или локальный адрес на который перенаправляются соединения
connectport - удаленный или локальный порт на который перенаправляются соединения

Для изменения уже существующего правила используется команда set v4tov4, которая имеет идентичный синтаксис, listenaddress и listenport - являются обязательными параметрами. Из необязательных параметров можно указывать только тот, который нужно изменить.

Для удаления правил используйте delete v4tov6 с указанием входящих адреса и порта:

netsh interface portproxy delete v4tov4 listenaddress=xxx.xxx.xxx.xxx listenport=nnn

Для просмотра существующих правил введите:

netsh interface portproxy show all

Вместо all допустимо указывать v4tov4 или v6tov4 и т.п. для просмотра только соответствующих правил.

Для сброса всех существующих правил используйте:

netsh interface portproxy reset

Чтобы не быть голословными рассмотрим практический случай использования portproxy в одной довольно непростой ситуации.

У одного нашего клиента имеется две аффилированных (т.е. принадлежащих одному владельцу) организации, имеющие разный вид деятельности и между собой не взаимодействующие. Одна из них находится в городе и не испытывает проблем с внешними коммуникациями. Вторая в сельской местности где доступен только среднего качества интернет, а о выделенном IP-адресе не может быть и речи.

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

Кроме того, выяснилось, что обе сети имеют одинаковый диапазон IP-адресов, что делало маршрутизацию между ними в принципе крайне затруднительной. По условиям задачи требовалось обеспечить доступ к RDP (порт 3389) сервера SRV-2-1 и SSH (порт 22) сервера SRV-2-2 второй организации, для этого выделялся сервер SRV-1-1 первой компании, при этом, как можно увидеть из схемы ниже, сервера обоих компаний также имеют одинаковые внутренние адреса.

Между серверами был поднят VPN-туннель, и они видят друг друга по адресам VPN-сети (10.8.0.0), а дальше на выручку приходит portproxy. Так как порты 3389 и 22 соответствующие нужным службам уже использовались для целей администрирования первой компании, то мы выбрали для служб второй компании внешние порты 3390 и 22222, которые были проброшены с внешнего интерфейса роутера первой компании на сервер SRV-1-1 штатным образом.

Теперь нам надо перенаправить все соединения на эти порты в сеть второй компании, но там нам доступен только SRV-2-1 по VPN-адресу, поэтому направим пакеты туда, для чего создадим два правила:

netsh interface portproxy add v4tov4 listenport=3390 listenaddress=192.168.0.200 connectport=3389 connectaddress=10.8.0.2
netsh interface portproxy add v4tov4 listenport=22222 listenaddress=192.168.0.200 connectport=22222 connectaddress=10.8.0.2

Первое правило отправит все пакеты пришедшие на порт 3390 с адресом 192.168.0.200 (внутренний адрес SRV-1-1) в VPN-туннель серверу SRV-2-1, а так как он уже является целевым для службы RDP, то сразу меняем порт назначения на 3389. Первая часть задачи выполнена.

Второе правило отправит к SRV-2-1 все пакеты с порта 22222 (SSH), теперь нам надо научить этот сервер как правильно доставить их адресату. Для этого добавим уже этому серверу следующее правило:

netsh interface portproxy add v4tov4 listenport=22222 listenaddress=10.8.0.2 connectport=22 connectaddress=192.168.0.201

Согласно которому сервер SRV-2-1 в сети второй компании будет слушать порт 22222 на интерфейсе VPN-сети и передавать все полученные пакеты на порт 22 (SSH) сервера SRV-2-2.

Как видим мы весьма просто реализовали довольно сложную схему, так пакет к серверу SRV-2-2 проходит три промежуточных узла, но при этом мы не настраивали никакой маршрутизации и не устанавливали никакого дополнительного ПО и вообще обошлись минимальным вмешательством в инфраструктуру.