Проксирование chromoting Chrome Remote Desktop через VPN

Да — проксировать трафик службы Windows chromoting (Chrome Remote Desktop) через раздельное туннелирование можно: служба обычно работает в процессе remoting_host.exe, и её можно направить через VPN в Nekobox по имени процесса или по доменам Google. Сначала определите PID и путь бинарника (tasklist /svc, sc qc, PowerShell), затем добавьте правило process_name или domain_suffix в конфиг Nekobox; учтите, что Chrome Remote Desktop использует UDP/TURN (порты 443 и 3478), и ваш VPN/прокси должен это поддерживать. Если перехват по процессу не срабатывает — используйте доменные правила, локальный SOCKS5‑прокси для конкретного процесса или изолируйте host в VM.

Содержание

• Как просмотреть процессы chromoting
• Настройка раздельного туннелирования Nekobox для Chrome Remote Desktop
• Проверка и отладка — как понять, что трафик идёт через VPN
• Альтернативы проксирования без правки системных маршрутов
• Источники
• Заключение

Как просмотреть процессы службы chromoting (Chrome Remote Desktop)

Коротко: служба Windows с именем сервиса chromoting обычно связана с исполняемым файлом remoting_host.exe (обычный путь — C:\Program Files\Google\Chrome Remote Desktop\remoting_host.exe). Подтверждение — в документации по процессам и в разборе исполняемого файла в сообществе и на сайтах с описанием процессов file.net и обзоре CRD winitpro.

Шаги для Windows (администраторский PowerShell/командная строка):

1. Быстрая проверка через tasklist:

tasklist /svc /fi "SERVICES eq chromoting"

Ожидаемый результат: строка с remoting_host.exe и PID, если служба запущена и привязана к этому процессу. Команда tasklist /svc упоминалась в официальной документации по поиску PID и сервисов (см. примеры в Microsoft Docs) — подробнее: https://learn.microsoft.com/ru-ru/windows-hardware/drivers/debugger/finding-the-process-id.

2. Посмотреть путь бинарника (чтобы точно знать имя exe):

sc qc chromoting

В выводе ищите BINARY_PATH_NAME — это полный путь к исполняемому файлу службы.

3. PowerShell — подробная информация через WMI/CIM:

Get-CimInstance -ClassName Win32_Service -Filter "Name='chromoting'" |
 Select-Object Name, State, ProcessId, PathName

По PID можно получить командную строку и путь процесса:

Get-CimInstance -ClassName Win32_Process -Filter "ProcessId=1234" |
 Select-Object Name, CommandLine, ExecutablePath

4. GUI: Откройте Диспетчер задач → вкладка «Подробности» (Details). Найдите remoting_host.exe по PID; правый клик → «Перейти к службам» / «Открыть расположение файла».

5. Для углублённой диагностики можно использовать Process Explorer (Sysinternals) — он покажет дерево процессов, дескрипторы, командную строку и путь.

Советы: запуск команд требует прав администратора для корректного получения PID/пути у системных служб. Если служба chromoting не отображается, ищите по отображаемому имени «Chrome Remote Desktop Service» в списке служб.

Настройка раздельного туннелирования Nekobox для Chrome Remote Desktop

Идея — либо направить конкретный процесс (remoting_host.exe) через VPN/outbound в Nekobox, либо перехватить трафик по доменам Google, которые использует CRD.

1. Правило по имени процесса (лучший вариант, если Nekobox перехватывает процессы службы):

• Пример JSON‑правила (адаптируйте outbound под ваш профиль Nekobox — например, "vpn", "proxy" или имя исходящего соединения):

{
 "rules": [
 {
 "process_name": ["remoting_host.exe"],
 "outbound": "proxy"
 }
 ]
}

Пример правила по аналогии с конфигом в руководстве по маршрутизации Nekobox: https://teletype.in/@forcheckmark/NekoRayRouting. После правки перезапустите Nekobox или примените конфиг заново.

2. Правило по доменам (если перехват процесса не сработал):

• Chrome Remote Desktop использует несколько доменов и TURN/STUN-сервисов; полезно добавить их в domain_suffix:
• remotedesktop.google.com
• remotedesktop-pa.googleapis.com
• instantmessaging-pa.googleapis.com

Пример:

{
 "rules": [
 {
 "domain_suffix": [
 "remotedesktop.google.com",
 "remotedesktop-pa.googleapis.com",
 "instantmessaging-pa.googleapis.com"
 ],
 "outbound": "proxy"
 }
 ]
}

Список доменов и общие сетевые требования описаны в справке Google по Chrome Remote Desktop: https://support.google.com/chrome/a/answer/16364503?hl=en.

3. ВАЖНО — UDP и порты:

• Chrome Remote Desktop активно использует UDP для STUN/TURN и может работать по TCP 443 как fallback. В справке Google упомянуты порты TCP 443 и UDP/TCP 3478, а также TURN‑серверы (в примере упоминается IP 74.125.247.128). Поэтому ваш VPN/прокси должен поддерживать UDP (или уметь туннелировать/пересылать UDP, либо иметь TURN‑совместимый релей). Если прокси поддерживает только TCP — CRD может не работать корректно. См. разбор особенностей в обзоре CRD: https://winitpro.ru/index.php/2021/05/19/udalennyj-rabochej-stol-google-chrome/ и официальную документацию: https://support.google.com/chrome/a/answer/16364503?hl=en.

4. Что делать, если process_name правило не срабатывает:

• Некоторое ПО (особенно службы, запущенные от SYSTEM) может не отлавливаться пользовательскими перехватчиками. В таком случае:
• Попробуйте запуск Nekobox с правами, необходимыми для перехвата системных процессов (если поддерживается).
• Используйте domain_suffix‑правила (они не зависят от привилегий процесса).
• Как запасной вариант — перенаправляйте весь трафик хоста CRD на уровне роутера (если есть доступ к маршрутизатору), либо запустите хост в виртуальной машине, в которой включён VPN.

Проверка и отладка — как понять, что трафик идёт через VPN

После настройки важно убедиться, что именно CRD/remoting_host.exe уходит через VPN:

1. По PID посмотреть текущие соединения:

• TCP:

Get-NetTCPConnection -OwningProcess <PID> |
 Select-Object LocalAddress, LocalPort, RemoteAddress, RemotePort, State

• UDP (Win10+):

Get-NetUDPEndpoint -OwningProcess <PID>

• Универсальный способ (netstat):

netstat -ano | findstr <PID>

Если вы видите удалённые адреса, принадлежность которых соответствует VPN‑сети — значит трафик проходит через неё.

2. Тест соединения к доменам CRD:

Test-NetConnection -ComputerName remotedesktop-pa.googleapis.com -Port 443
nslookup remotedesktop.google.com

Это проверит TCP/443; UDP/TURN проверить труднее без специальных инструментов (nmap, wireshark). Помните: DNS может резолвиться по‑разному, если Nekobox не перехватывает DNS-запросы.

3. Практический тест: подключитесь к машине удалённо по Chrome Remote Desktop с клиента, находящегося вне VPN‑сети. Если соединение проходит нормально — конфигурация рабочая. Если нет — смотрите логи Nekobox и логи CRD (в реестре/диспетчере событий) на ошибки по установке сессии или TURN.

4. Возможные причины, если не работает:

• Nekobox не запускается с нужными правами и не перехватывает системный процесс.
• VPN/прокси не поддерживает UDP/TURN.
• Использован только TCP‑проксирование (недостаточно для полноценного соединения).
• CRD может обращаться к множеству IP Google (CDN), IP‑список меняется — IP‑маршруты по одному адресу ненадёжны.

5. Полезная последовательность отладки:

• Убедиться, что sc qc chromoting показывает тот самый remoting_host.exe.
• Проверить, что правило Nekobox действительно содержит remoting_host.exe или нужные домены.
• Перезапустить Nekobox и службу Chrome Remote Desktop.
• Собирать сетевые логи и смотреть удалённые адреса (через PowerShell/netstat/Resource Monitor).

Альтернативы проксирования без правки системных настроек

Если по каким‑то причинам направить chromoting через Nekobox не получается, есть несколько вариантов, которые не требуют глобальной правки системной таблицы маршрутизации:

• Перенаправление по доменам в самом Nekobox (мы уже описали) — не меняет системные маршруты, работает на уровне приложения/прокси.
• Пер‑приложенческое проксирование (Proxifier/ProxyCap и аналоги): ставите программу, задаёте правило для remoting_host.exe — она будет форс‑перехватывать соединения данного исполняемого файла. Минус: многие такие инструменты ориентированы на TCP; для UDP нужен SOCKS5 с поддержкой UDP или дополнительный туннель.
• Запуск Chrome Remote Desktop Host внутри виртуальной машины/контейнера, где внутри включён VPN. В этом случае хост CRD «видит» VPN‑интерфейс, а основная система остаётся без изменений.
• Роутер‑уровень (если доступен): настройка раздельного туннелирования на маршрутизаторе (например, Keenetic/другие прошивки) — тогда внешние сервисы идут через VPN, а остальной трафик — напрямую. Это не меняет маршруты на целевой машине, но требует доступа к роутеру.
• Собственный релей/обход (reverse SSH/SOCKS на VPS) — более ручной и сложный путь: поднять внешний сервер с российским IP и делать реверс‑туннель/relay для конкретных портов. Работоспособность зависит от того, можно ли заставить CRD использовать такой релей (обычно — нет, т.к. CRD использует Google‑relay).

Замечание по надёжности: если VPN/прокси не поддерживает UDP и TURN, многие попытки «прибить» только часть трафика не обеспечат стабильную работу CRD; иногда проще настроить изолированный VPN для всего хоста CRD (VM) или использовать доменные правила + полнофункциональный VPN.

Источники

• Finding the Process ID (PID) in Windows — Microsoft Docs
• remoting_host.exe — file.net
• Network guide for Chrome Remote Desktop — Chrome Enterprise Help
• Пример JSON‑правил для Nekobox / NekoRayRouting — Teletype
• Разбор Chrome Remote Desktop (служба chromoting, remoting_host.exe) — WinitPro
• Обсуждение Chrome Remote Desktop и VPN — Reddit r/VPN
• Split‑tunnel обсуждение RDP/SSH — Reddit r/HomeNetworking
• VPN traffic routing and RDP — Superuser
• Как определить процесс, связанный с программой — Windows‑School

Заключение

Проксирование службы chromoting (Chrome Remote Desktop) через раздельное туннелирование реалистично: начните с обнаружения процесса remoting_host.exe (или PID сервиса chromoting) и пропишите правило process_name в Nekobox, либо — надёжнее — добавьте domain_suffix для доменов Chrome Remote Desktop. Главное — убедиться, что ваш VPN/прокси поддерживает UDP/TURN и порты 443/3478; без этого CRD будет работать некорректно. Если перехват процесса не срабатывает, пробуйте доменные правила, локальный SOCKS5‑перехват для процесса или запуск хоста в VM — это сохранит основную систему без глобальных изменений и решит проблему с блокировками РКН.