Используйте Windows 11 для перенаправления трафика между двумя ЛВС

У меня Windows 11 с IP-адресами 192.168.72.100 и 192.168.10.113, подключенными к двум локальным сетям:

192.168.10.1/24
192.168.72.1/24

С хоста в сети 192.168.10.1/24 я хотел бы сделать ping и http/vnc к машине в сети 192.168.72.1/24.

Я установил HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\IPEnableRouter в 1 и перезагрузил Windows. Я включил RemoteAccess с помощью:

sc config RemoteAccess start=auto
sc start RemoteAccess

Но с хоста в сети 192.168.10.1/24 я не могу сделать ping к узлам в сети 192.168.72.1/24, кроме самой Windows-машины:

ping 192.168.72.101
PING 192.168.72.101 (192.168.72.101): 56 байт данных
(зависает навсегда)

Я могу сделать ping к Windows-машине без проблем:

ping 192.168.72.100
PING 192.168.72.100 (192.168.72.100): 56 байт данных
64 байта от 192.168.72.100: seq=0 ttl=127 time=0.638 ms
64 байта от 192.168.72.100: seq=1 ttl=127 time=0.591 ms

Я отключил брандмауэр Windows Defender.

Что еще мне нужно сделать, чтобы разрешить ping (и http/vnc) в этой ситуации?

Хотя ваша сеть 192.168.10.0/24 имеет действующий маршрут к сети 192.168.72.0/24, у вас отсутствует обратный маршрут из 192.168.72.0/24 в 192.168.10.0/24.

Пакеты “Reply” не знают автоматически своего обратного маршрута; каждый пакет маршрутизируется независимо, не делая различий между исходным пакетом и пакетом ответа. Другими словами, когда устройства получают IP-пакет, они не запоминают, от какого MAC-адреса он пришел, и не просто отправляют ответы тем же способом¹, а выполняют новый поиск маршрута и новый запрос ARP.

¹ (Помимо странной прошивки “SwOS” от Mikrotik, которая делает именно это.)

В результате:

• Ваше устройство 192.168.72.x настроено с маской подсети /24, поэтому оно распознает Windows ПК 192.168.72.y как адрес “локальной подсети” (для которого у него автоматически есть прямой маршрут) и способно отвечать на пинги, напрямую запрашивая ARP для MAC-адреса ПК.

• В то же время, когда его пингуют с 192.168.10.x, устройство правильно распознает 192.168.10.x как не-локальный адрес и знает, что пакеты ответов должны доставляться через MAC-адрес шлюза. Но поскольку у устройства не настроен стандартный шлюз (или статический маршрут), у него нет возможности отправить пакет ответа.

Поэтому устройствам 192.168.72.x необходимо иметь либо конкретный маршрут к 192.168.10.0/24 через Windows маршрутизатор, либо стандартный маршрут, чтобы как-то сообщить им, куда доставлять пакеты.

В качестве обходного пути промежуточный маршрутизатор может выполнять SNAT (или маскировку), заменяя IP-адрес оригинального отправителя своим собственным адресом, который, конечно, будет “локальным” для устройства. Например, в OpenWRT SNAT включен по умолчанию для всего трафика “LAN→WAN” (как обычно ожидалось от домашнего беспроводного маршрутизатора), поэтому всё работает, когда вы используете маршрутизатор OpenWRT посередине – при условии, что SNAT включен в правильном направлении.

Похоже, что Windows 10/11 поддерживает NAT нативно, и вы можете включить его с помощью Add-NetNat в PowerShell (это то, что используется для Hyper-V WSL2, так что я не уверен на 100%, сработает ли это без установленного Hyper-V). Укажите 192.168.72.0/24 как “внешний” префикс.

(Аналогично, функция “Совместное использование интернет-соединения” всегда выполняет NAT, хотя также накладывает некоторые другие жесткие конфигурации и, вероятно, слишком неэффективна для вашей настройки.)

Ранее также существовала реализация NAT как часть RRAS (по крайней мере, в Server 2003), но я подозреваю, что она могла быть удалена в пользу новой.

Но, вероятно, будет лучше продолжать использовать устройство OpenWRT в качестве маршрутизатора, или, по крайней мере, загрузить Linux или *BSD на ПК – хотя Windows может маршрутизировать, это далеко от идеала для этой цели.