Доступ к серверу за NAT

Захотелось собрать в единую кучку все известные мне способы достучаться до своего (или не очень своего) сервера, который расположен где то в локации X за неким роутером с NAT. При этом прямого VPN нет, публичного IP нет, SourceNAT может быть и не один (например сначала на домашнем роутере, а потом на роутере провайдера).

Первыми будут сторонние и ограниченно бесплатные решения, далее решения самодельные, с большим контролем с нашей стороны.

Общий перечень рассматриваемых способов:

1. TeamViewer, AnyDesk, AmmyAdmin, Ассистент, RuDesktop (и т.д. - более 20 продуктов в настоящее время)

2. TailScale, ZeroTier (и их аналоги)

3. VPN Tunnel и его использование с помощью Nginx/SSH/SecondVPN/iptables (PREROUTING + POSTROUTING)

4. SSH Tunnel + Reverse Port Mapping

5. IPv6 TEREDO Tunnel

Нестареющая классика

Про продукты TeamViewer, AnyDesk, AmmyAdmin, Ассистент, RuDesktop, "RMS Удаленный доступ" и им подобные не слышали наверное только люди, сильно далекие от ПК и удаленной работы. TeamViewer, например, появился аж в 2005-м году - и тем не менее до сих пор актуален и востребован.

Плюсы продуктов:

• Максимальная простота использования (мамам и бабушкам ярлык на рабочий стол - УДАЛЕННАЯ ПОМОЩЬ!!!)

• Бесплатность при умеренных аппетитах (либо понимании, как сменить MAC-адрес, почистить реестр и т.п. хаки)

Недостатки:

• Дыра в безопасности (вспоминаем недавнюю новость про взлом AnyDesk)

• Санкции от западных компаний (но уже есть отечественные решения и не одно)

• Зависимость от третьей стороны (и отсюда возможные просадки по скорости, недоступность сервиса и другие приколы)

Хипстеры - новоделы

Название не для того, чтобы обидеть кого-то - а чтобы показать, что это достаточно современные технологии - например, компания TailScale основана в 2019-м году. ZeroTier существенно раньше (2011-й), но популярность завоевала не так уж и давно.

Хорошее описание и сравнение их возможностей можно почитать тут.

Плюсы продуктов:

• Строим единую сеть на серых IP-адресах поверх UDP-туннелей и сети Интернет. Максимально быстро, с минимумом усилий.

Недостатки:

• Бесплатно только на малое количество узлов

• Санкции (TailScale уже блочит, остальные вопрос времени)

VPN туннель

Как построить VPN туннель с помощью дешевого VPS хостинга с белым IP и OpenVPN, я описал в прошлой своей статье тут. Выбор VPS и технологии остается за Вами - каждому свое. После того, как у нас будет внешний публичный IP и есть туннель с двумя IP-адресами на концах, у нас есть масса способов достичь портов на сервере за NAT:

1. Reverse Proxy, например Nginx:

   1. Хорош в ситуации, когда схему нужно масштабировать - например, у нас возможно будет не один туннель и не один сервер за NAT.

   2. Хорош, когда всем нужен один и тот же порт публиковать (HTTP/HTTPS как самые частые). Тогда Nginx будет принимать и обрабатывать запросы сам, и уже на основании URL адреса, направлять запросы на BackEnd в нужный VPN туннель на IP-адрес удаленной стороны (сервера за NAT)

2. SSH - VPS у нас скорее всего будет на Linux (FreeBSD) и в этом случае у нас есть SSH доступ. Пользуясь технологией SSH Tunnel, мы легко опубликуем себе любое приложение, если оно работает по TCP (еще один SSH/RDP/VNC/etc).

3. Second VPN - допустим у нас полно IP-адресов за NAT и полно TCP/UDP портов, к которым нам хочется попасть. В этом случае логичнее поднять на VPS еще один VPN клиентского типа (например, OpenConnect). Подключаемся к VPS с публичным IP, обращаемся через первый VPN туннель куда нам нужно. Этот способ потребует от нас включение на Linux VPS сервере маршрутизации (net.ipv4.ip_forward) и скорее всего SourceNAT/Masquerade нашего SourceIP IP-адресом туннеля (чтобы принимающие от нас узлы видели SourceIP, который им доступен). Иногда возможно даже дважды придется сделать SourceNAT, но это не проблема.

4. iptables (PREROUTING + POSTROUTING). Если нет возможности ни делать SSH туннель, ни VPN туннель (например, у нас ПО для специфичной IP-камеры) - можно просто сделать пару правил в iptables, и смаппить свободный TCP/UDP порт на публичном IP у VPS внутрь в туннель на сервер за NAT. При этом, чтобы не сломать обратную маршрутизацию, sourceIP на выходе спрятать другим концом туннеля (SNAT).
   Пример:

   iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 22222 -j DNAT --to 10.90.90.2:22
   iptables -t nat -A POSTROUTING -o tun0 -d 10.90.90.2 -p tcp --dport 22 -j SNAT --to 10.90.90.1

   В этом примере у нас на VPS Linux есть два интерфейса (eth0 - с белым IP) и tun0 (OpenVPN туннель. На стороне VPS: 10.90.90.1, на стороне сервера за NAT - 10.90.90.2). Первое правило перекидывает коннекты на Public IP на порт TCP/22222 в сторону сервера за NAT, в IP: 10.90.90.2, порт TCP/22. Второе правило отрабатываем в момент, когда трафик уже готов покинуть сервер и улететь в tun0. SourceIP реального подключающегося клиента (какой то другой белый IP из сети Интернет) подменяется на 10.90.90.1. Итого принимающий сервер за NAT получает подключение и знает, куда отвечать. Схема проверена годами, хорошо работает и для TCP и для UDP.

SSH Tunnel + Reverse Port Mapping

Иногда сервер за NAT вообще не наш, и кроме команды SSH мы не можем ничем воспользоваться (хорошо, если еще есть screen или tmux, но можно и без них).

Решение для таких экстремальных ситуаций (внешний сервер с белым IP и доступным работающим SSH):

ssh \
	-o ServerAliveInterval=60 \
	-o ServerAliveCountMax=5 \
	-p <ssh-port> \
	-l <ssh-login> \
	-R <public-external-ip>:<port-inside-tunnel>:<behind-nat-private-ip>:<port-destination> \
	<public-external-ip>

Подключаемся на указанный публичный IP, на нужный нам SSH-порт с указанным юзером. Соединение раз в минуту шлет KeepAlive пакеты, поддерживая записи в NAT таблице на пограничных роутерах. На внешнем SSH сервере для нас открывается port-inside-tunnel, при обращении к которому мы попадаем на behind-nat-private-ip (и этом может быть вообще не сервер за NAT, а его соседний узел, доступный с него через маршрутизацию и на port-destination. Схема отлично работает для SSH и для RDP, пользуюсь много лет.

IPv6 TEREDO Tunnel

Хорошая и работающая (пока) технология в России. Для Linux устанавливаем пакет miredo, исправляем в конфиге адрес сервера на win10.ipv6.microsoft.com, запускаем как службу. Через несколько секунд у нас будет сетевуха teredo0 с приватным IPv6 адресом.

Для Windows 10 пример использования тут:

# Посмотреть текущее состояние:
netsh interface teredo show state

# Установить адрес работающего Teredo сервера
netsh interface teredo set state servername=win10.ipv6.microsoft.com

# Включить клиент Teredo
netsh interface teredo set state natawareclient

# Через ipconfig посмотреть, что появилось:

Туннельный адаптер Teredo Tunneling Pseudo-Interface:

   DNS-суффикс подключения . . . . . :
   IPv6-адрес. . . . . . . . . . . . : 2001:0:2851:782c:28e6:1483:xxxx:xxxx
   Локальный IPv6-адрес канала . . . : fe80::28e6:1483:a1d6:efba%11
   Основной шлюз. . . . . . . . . : ::

# посмотреть более детальный статус о туннеле:
netsh interface teredo show state

C:\Windows\system32>netsh interface teredo show state
Параметры Teredo
---------------------------------------------
Тип                         : natawareclient
Имя сервера                 : win10.ipv6.microsoft.com
Интервал обновления клиента : 30 секунд
Порт клиента            : unspecified
Состояние               : qualified
Тип клиента             : teredo client
Сеть                 : unmanaged
NAT                     : restricted (port)
Особое поведение NAT : UPNP: Нет, Сохранение портов: Да
Локальное сопоставление : 192.168.1.100:60284
Внешнее сопоставление NAT : 94.41.XX.XX:60284

# Воспользоваться...

# Наигрались - отключаем
netsh interface teredo set state disabled

SSH, RDP, etc - работает внутри этой приватной сети без проблем.

Эпилог

Не рассмотрел netcat (так как не пользуюсь), но он есть, да (как суслик). Естественно думаем про безопасность, поэтому фильтруем коннекты на Firewall, ставим патчи, делаем сложные пароли, используем Port Knock, etc...

А Вы какими способами пользуетесь? Буду рад узнать что-то новое.