IAP Desktop — полезная программа под Windows, которая управляет несколькими удалёнными десктопами и устанавливает туннели SSH/RDP к разным виртуальным машинам под Linux и Windows. Она сочетает преимущества стандартного менеджера RDP-соединений с безопасностью и гибкостью Identity-Aware Proxy (IAP-прокси).

В 2022 году такой инструмент очень актуален, с распространением облачных сервисов и хостингов, где могут крутиться наши виртуальные машины и контейнеры. А также в связи с необходимостью удалённого доступа по RDP и SSH к разным корпоративным виртуалкам.

▍ IAP Desktop

Опенсорсный клиент IAP Desktop позволяет подключаться не только к контейнерам в облаке Google Cloud, но и к любым другим VM через IAP-прокси. При этом коннект возможен из любой точки мира, а не только из внутренней сети. Утилита подключается даже к инстансам, у которых нет публичного IP-адреса или доступа в интернет через NAT (как это организовано на уровне архитектуры IAP, чуть ниже).

Поскольку туннель для TCP-форвардинга устанавливается по HTTPS, вы можете подключиться к своей рабочей машине даже из-за корпоративного файрвола или прокси.

Программа маленькая (4 МБ), устанавливается за полсекунды, что в эпоху засилья Electron просто удивительно:



Интерфейс крайне простой, всего несколько кнопок с очевидной функциональностью:



Как видим, разные туннели SSH и соединения RDP просто открываются в разных вкладках, а мы переключаемся между ними как в стандартном интерфейсе с табами. Каждая вкладка — отдельный инстанс в своём облаке или на каком-то хостинге. Это могут быть виртуалки на CentOS, Debian, Ubuntu или на разных версиях Windows. Всё подключается по стандартному протоколу Remote Desktop Protocol (RDP) или SSH.



Требования для установки IAP Desktop:

• ОС Windows 8, Windows Server 2012 или выше
• доступ в интернет (хотя бы к Google API), напрямую, через NAT, или через HTTP-прокси;
• для клиента на рабочей машине не требуются права администратора, если только он не установлен на Windows Server, где административные права нужны обязательно — из-за специфического туннелирования RDP программа принимает только аутентификацию NTLM и не может использовать Kerberos;
• нужен проект Google Cloud с правами владельца или хотя бы со следующими ролями:
  
  • Compute Viewer (для просмотра списка VM и доступа к инстансам);
  • IAP-secured Tunnel User (для форвардинга IAP TCP).
  
  
  
  
• правило файрвола, разрешающее доступ Identity-Aware-Proxy к инстансам VM.
  
  Это правило в Google Cloud можно задать следующей командой:
  
  

  gcloud compute firewall-rules create allow-rdp-ingress-from-iap \
  --direction=INGRESS \
  --action=allow \
  --rules=tcp:3389,tcp:22 \
  --source-ranges=35.235.240.0/20

После установки IAP Desktop запрашивает доступ к личным данным и проектам в Google Cloud:



В следующем окне необходимо обязательно поставить нижнюю птичку:



В диалоге Add projects добавляем проекты.



Для каждого проекта отобразятся доступные виртуальные машины.



К каждой из них можно подключиться в отдельной вкладке, как говорилось выше.

Для подключения к Windows VM по RDP можно сгенерировать новые учётные данные, чтобы создать на инстансе Windows-пользователя и подключиться через него. Как вариант, можно подключиться без создания отдельного юзера. В любом случае IAP Desktop автоматически создаст туннель для переадресации TCP и подключится к машине по RDP:



Посмотрим немного подробнее, как работает прокси IAP и механизм форвардинга TCP.

▍ TCP-форвардинг

Функция переадресации (форвардинга) TCP позволяет подключаться к произвольным TCP-портам инстансов в облаке, например, на Compute Engine. Как показано на иллюстрации, к одной виртуальной машине идёт обращение по порту TCP 22, а к другой — по TCP 3389.



Для обычного TCP-трафика прокси IAP на локальном хосте создаёт один порт, который перенаправляет весь трафик на определённый инстанс. Затем IAP оборачивает весь трафик от клиента в HTTPS. После аутентификации и авторизации пользователь получает доступ к этому интерфейсу и порту, если у него имеются соответствующие права в политике управления идентификацией и доступом целевого ресурса (Identity and Access Management, IAM).

Особый случай — соединение SSH, созданное командой gcloud compute ssh. Оно оборачивает SSH-туннель в HTTPS и сразу направляет на удалённый инстанс. Таким образом, исчезает необходимость в прослушивании порта на локальном хосте.

Включение IAP-прокси для управления доступом не блокирует автоматически прямые запросы к ресурсам. Блокируются только TCP-запросы к соответствующим службам, поступающие с других IP-адресов, не указанных в конфигурации IAP TCP forwarding IPs.

Как уже было сказано, TCP-форвардинг с IAP не требует наличия публичного IP-адреса, он использует только внутренние адреса.

▍ Функции прокси

Таким образом, TCP-форвардинг с IAP выполняет следующие цели:

1. Централизованное управление и контроль. Если у нас много инстансов и VM, то благодаря IAP мы получаем удобный способ удалённого управления ими, в том числе с десктопа под Windows.
   
2. Защита приложений и инстансов.
   
3. Совместимость с другими облаками и своим собственным хостингом.

Самое главное, что IAP может защищать приложения не только на Google Cloud, но также в других облаках и на своём хостинге.

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

Десктопный клиент IAP помогает удалённым работникам, которые получают доступ к корпоративным приложениям через публичный URL в браузере, без необходимости запускать VPN-клиент.

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

Если обобщить, то IAP создаёт централизованный уровень авторизации для приложений по HTTPS. Здесь мы используем модель контроля доступа на уровне приложений вместо файрволов сетевого уровня.

Политики IAP масштабируются на всю организацию. Их можно определять централизованно и применять сразу ко всем своим приложениям и ресурсам.

▍ Универсальный прокси

IAP Desktop — опенсорсная программа под лицензией Apache 2.0, её можно свободно использовать в любых своих сервисах, в том числе коммерческих. В том числе для проксирования доступа к сервисам на собственных серверах (on-premise). Инструкции по настройке IAP для доступа к приложению на собственном хостинге см. здесь.

В данном случае схема выглядит так:



Практически на любом хостинге можно поднять контейнер с RDP или SSH-сервером — и подключиться к нему по RDP или SSH. Прокси IAP демонстрирует общую методологию для управления виртуальными машинами на разных облаках по типу TCP-over-HTTPS. Например, нечто подобное можно организовать с помощью stunnel, sslh и traefik или ghostunnel вместо stunnel, авторизация в приложениях Docker/Kubernetes через JWT Auth Proxy внутри IAP примерно по такой схеме:

IAP = внутри GCP => (JWT proxy -> ghostunnel) = через NAT наружу => (ghostunnel -> клиент)

С точки зрения пользователей очень удобно поднимать в дата-центре отдельные приложения или сервисы в контейнерах (микро VM), к которым всегда есть прямой доступ по SSH или RDP.

IAP тоже работает по схеме TCP-over-HTTPS, соединяя всё что угодно друг с другом. Для пользователя это выглядит предельно просто: авторизовался с Google — и подключаешься к любым удалённым машинам в одно нажатие кнопки. И аккаунт Google даже не обязателен: вместо него IAP может использовать аутентификацию по e-mail/паролю, OAuth (Google, Facebook, Twitter, GitHub, Microsoft и др.), SAML, OIDC, по номеру телефону и что угодно другое. Можно вообще разрешить анонимный доступ к приложению.

TCP-over-HTTPS используется как универсальный прокси-посредник для установления зашифрованных соединений между любыми приватными сетями, у которых нет публичных интерфейсов:



Вот пример программы в 20 строчек на Rust, которая соединяет приватные сети или клиент с сервером через любое публичное облако, где установлен узел Ockam.

Аналогичный безопасный туннель можно установить с помощью опенсорсного приложения OpenZiti. По сути, это принцип туннелирования с шифрованием в небезопасной сети (zero trust networking) без использования VPN.



Таким образом, принципы IAP отлично подходят для соединения между собой по SSH и RDP любых сервисов, клиентов и приложений на любых хостингах.

Кто-то может спросить, зачем в наше время вообще нужен Windows Server и протокол RDP. Но осталась ещё масса приложений, которые традиционно работают под Windows. На практике получается, что иногда проще поднять на Linux-сервере какой-нибудь контейнер с Windows, чем изменять весь рабочий процесс и переходить на Linux-софт. А что касается протокола RDP, то это уже давно не проприетарная игрушка Microsoft, сейчас даже под Linux он обеспечивает бóльшую эффективность, чем VNC, в некоторых приложениях.

Или вы можете поднять где-то в облаке Windows-виртуалку, чтобы поиграть в игру на мощном компьютере, если домашний ноут не тянет или не поддерживает эту игру, эдакий приватный вариант сервиса GeForce Now или покойной Stadia.

Telegram-канал с полезностями и уютный чат