Содержание

Ограничения для URI перенаправления (URL-адресов ответа) — Microsoft Entra

  • Статья
  • Чтение занимает 5 мин

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

Модель приложения Azure Active Directory (Azure AD) определяет следующие ограничения для URI перенаправления:

  • URI перенаправления должен начинаться со схемы https

    . Существуют некоторые исключения для URI перенаправления localhost.

  • URI перенаправления чувствительны к регистру и должны соответствовать регистру URL-пути выполняемого приложения. Например, если приложение включает в состав своего пути .../abc/response-oidc, не указывайте .../ABC/response-oidc в URI перенаправления. Так как веб-браузер обрабатывает пути с учетом регистра, файлы cookie, связанные с .../abc/response-oidc, могут быть исключены при перенаправлении на не совпадающий по регистру знаков URL-адрес .../ABC/response-oidc.

  • URI перенаправления без сегмента пути возвращаются с замыкающей косой чертой (

    /) в ответе. Это применимо только в том случае, если режим ответа имеет значение query или fragment.

    Примеры:

    • https://contoso.com возвращается в виде https://contoso.com/
    • http://localhost:7071 возвращается в виде http://localhost:7071/

  • К URI перенаправления, содержащих сегмент пути, не добавляется замыкающая косая черта в ответе.

    Примеры:

    • https://contoso.com/abc возвращается в виде https://contoso.com/abc
    • https://contoso.com/abc/response-oidc возвращается в виде https://contoso.com/abc/response-oidc

Максимальное число URI перенаправления

В этой таблице указано максимальное число URI перенаправления, которые можно добавить для зарегистрированного приложения на платформе удостоверений Майкрософт.

Учетные записи для входаМаксимальное число URI перенаправленияОписание
Рабочие или учебные учетные записи Майкрософт в клиенте Azure Active Directory (Azure AD) любой организации256Для поля signInAudience в манифесте приложения установлено AzureADMyOrg
или AzureADMultipleOrgs
Личные учетные записи Майкрософт и рабочие и учебные учетные записи100Для поля signInAudience в манифесте приложения установлено AzureADandPersonalMicrosoftAccount

Максимальное число URI перенаправления не может быть увеличено по соображениям безопасности. Если вам требуется большее число URI перенаправления, используйте следующую схему с параметром состояния в качестве решения.

Максимальная длина URI

Длина каждого URI перенаправления, добавляемого для зарегистрированного приложения, должна составлять не более 256 символов.

Перенаправление URI в главных объектах приложений и субъектов-служб

  • Всегда добавляйте URI перенаправления только к объекту приложения.
  • Не добавляйте значения URI перенаправления к субъекту-службе, так как эти значения могут быть удалены при синхронизации объекта субъекта-службы с объектом приложения. Это может произойти из-за любой операции обновления, которая запускает синхронизацию между двумя объектами.

Поддержка параметров запроса в URI перенаправления

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

Параметры запроса запрещены в URI перенаправления для регистрации приложений, настроенных для входа пользователей с помощью личных учетных записей Майкрософт, таких как Outlook.

com (Hotmail), Messenger, OneDrive, MSN, Xbox Live или Microsoft 365.

Аудитория входа в систему регистрации приложенийПоддерживает параметры запроса в URI перенаправления
Учетные записи только в этом каталоге организации (только Contoso — один арендатор)
Учетные записи в любом каталоге организации (любой каталог Azure AD — несколько арендаторов)
Учетные записи в любом каталоге организации (любой каталог Azure AD — несколько арендаторов) и личные учетные записи Майкрософт (например, Skype, Xbox)
Только личные учетные записи Майкрософт

Поддерживаемые схемы

HTTPS: схема HTTPS (https://) поддерживается для всех URI перенаправления на базе протокола HTTP.

HTTP: схема HTTP (http://) поддерживается только для URI перенаправления localhost и используется исключительно на этапах локальной разработки и тестирования приложения.

Пример URI перенаправленияСрок действия
https://contoso.com
Допустимо
https://contoso.com/abc/response-oidcДопустимо
https://localhostДопустимо
http://contoso.com/abc/response-oidcНедопустимо
http://localhostДопустимо
http://localhost/abcДопустимо

Исключения для localhost

В соответствии с разделами RFC 8252 8.3 и 7.3, для URI перенаправления с замыканием на себя (localhost) действуют два особых правила:

  1. Схемы URI http допустимы, поскольку перенаправление никогда не покидает устройство. Таким образом, приемлемыми являются оба этих URI:
    • http://localhost/myApp
    • https://localhost/myApp
  2. Из-за временного характера диапазонов портов, часто используемых собственными приложениями, компонент порта (например, :5001 или :443) при сопоставлении URI перенаправления игнорируется. В результате все эти URI считаются эквивалентными:
    • http://localhost/MyApp
    • http://localhost:1234/MyApp
    • http://localhost:5000/MyApp
    • http://localhost:8080/MyApp

С точки зрения разработки это означает несколько моментов:

  • Не регистрируйте несколько URI перенаправления, если в них различается только порт. Сервер входа будет произвольным образом выбирать один из них и использовать связанные с этим URI параметры (например, в зависимости от того, относится ли это перенаправление к типу web, native, или spa).

    Это особенно важно, если вы планируете использовать в одном зарегистрированном приложении разные потоки проверки подлинности (например, и выдачу кода авторизации, и неявный поток). Чтобы связать с каждым URI перенаправления правильные параметры ответа, сервер входа должен иметь возможность различать эти URI, что невозможно, если различается только порт.

  • Чтобы зарегистрировать несколько URI перенаправления по адресу localhost для тестирования различных потоков в процессе разработки, используйте для них разный компонент пути. Например, http://localhost/MyWebApp не эквивалентно http://localhost/MyNativeApp.

  • IPv6-адрес замыкания на себя ([::1]) в настоящее время не поддерживается.

Выбор 127.0.0.1 вместо localhost

Чтобы работу приложения не нарушали неправильно настроенные брандмауэры или переименованные сетевые интерфейсы, используйте в URI перенаправления IP-адрес замыкания на себя в виде localhost вместо 127.0.0.1. Например, https://127.0.0.1.

При этом текстовое поле URI перенаправления на портал Azure нельзя использовать для добавления URI замыкания на себя со схемой http:

Чтобы добавить URI перенаправления, использующий схему http с 127. 0.0.1-адресом замыкания на себя, в настоящее время необходимо изменить атрибут replyUrlsWithType в манифесте приложения.

Ограничения на подстановочные знаки в URI перенаправления

URI с подстановочными знаками, такие как https://*.contoso.com, кажутся удобными, но их следует избегать из-за проблем с безопасностью. Согласно спецификации OAuth 2.0 (раздел 3.1.2 RFC 6749), URI конечной точки перенаправления должен быть абсолютным.

URI с подстановочными знаками в настоящее время не поддерживаются для зарегистрированных приложений, настроенных для входа как в личные, так и в рабочие и учебные учетные записи Майкрософт. Однако подстановочные знаки в URI разрешены для приложений, которые настроены для входа только в рабочие или учебные учетные записи в арендаторе Azure AD организации.

Чтобы добавить URI перенаправления с подстановочными знаками для зарегистрированных приложений, которые входят в рабочие или учебные учетные записи, используйте редактор манифеста приложения в разделе Регистрация приложений на портале Azure. Хотя с помощью редактора манифеста действительно можно задать URI перенаправления с подстановочными знаками, мы настоятельно рекомендуем придерживаться требований раздела 3.1.2 RFC 6749 и использовать только абсолютные URI.

Если вам требуется больше URI перенаправления, чем разрешено, вместо подстановочных знаков вы можете воспользоваться следующей схемой с параметром состояния.

Использование параметра состояния

Если у вас есть несколько поддоменов и вам необходимо после успешной проверки подлинности перенаправлять пользователей на ту же страницу, с которой они начали, можно использовать параметр состояния.

Если вы используете этот подход:

  1. Создайте «общий» URI перенаправления для каждого приложения, чтобы обрабатывать маркеры безопасности, полученные от конечной точки авторизации.
  2. Приложение может отсылать параметры, зависящие от приложения (например, URL-адрес поддомена, откуда перешел пользователь, или настройки фирменного оформления), в параметр состояния. При использовании параметра состояния необходимо предотвратить защиту CSRF, как указано в разделе 10.12 стандарта RFC 6749).
  3. Параметры, зависящие от приложения, будут включать всю информацию, необходимую приложению для корректного отображения для пользователя, то есть для создания соответствующего состояния приложения. Конечная точка авторизации Azure AD удаляет HTML-код из параметра состояния, поэтому не передавайте HTML-содержимое в этом параметре.
  4. Когда Azure AD отправляет ответ на общий URI перенаправления, он отправляет параметр состояния обратно в приложение.
  5. Затем приложение может использовать значение в параметре состояния, чтобы определить URL-адрес для отправки пользователю. Убедитесь, что вы проверили защиту CSRF.

Предупреждение

Такой подход позволяет скомпрометированному клиенту изменять дополнительные параметры, отправляемые в параметре состояния, поэтому пользователь перенаправляется на другой URL-адрес, что является угрозой открытого перенаправления, как описано в стандарте RFC 6819. Таким образом, клиент должен защищать эти параметры, шифруя состояние или проверяя его с помощью других средств, таких как проверка доменного имени в URI перенаправления по маркеру.

Дальнейшие действия

Узнайте о манифесте регистрации приложения.

Расширенное использование SSH / Хабр

Протокол SSH v.2 является важной составляющей безопасных компьютерных сетей. Он криптографически надёжен, быстр, универсален и широко распространён. Многие крупные облачные провайдеры даже не пытаются заменить его каким-либо альтернативным, собственным решением, что подчёркивает его силу. 

В этой статье я хочу продемонстрировать некоторые интересные и универсальные возможности протокола SSH и его реализации OpenSSH. 

Возможности клиента OpenSSH (ssh, scp, sftp)

Сначала рассмотрим особенности клиентских возможностей OpenSSH — не затрагивая настройки серверной стороны. 

Хранение конфигурации в ~/.ssh/config

OpenSSH имеет мощный механизм настройки клиента, который, на мой взгляд, недооценён людьми, использующими ssh во время ежедневной работы. Имею в виду текстовый файл с расположением по умолчанию .ssh/config в домашнем каталоге каждого пользователя. Его отсутствие не мешает ssh при вызове, но, если вы будете использовать его правильно, он может значительно облегчить вам жизнь.

Я часто замечал, что некоторые настраивают alias в своей оболочке, чтобы подстроить ssh под себя. В большинстве случаев вы можете заменить любой alias, определяющий параметры OpenSSH, несколькими строками в конфигурационном файле. Это удобнее, ведь другие инструменты, предоставляемые OpenSSH, также подхватят набор нужных параметров.

В качестве примера, предположим, что у вас есть хост с именем crunch.example.com, с sshd, прослушивающим порт 2222 (вместо 22 по умолчанию), и вам нужен определенный SSH-идентификатор, расположенный по адресу ~/.id_c для подключения.

Вы можете решить эту проблему, создав псевдоним оболочки вида crunch='ssh -p2222 -i~/. id_c crunch.example.com' в одном из ваших файлов конфигурации оболочки, и использовать его всякий раз, когда вам нужно войти в crunch по ssh. Это удобно, если только вам не нужно перенести некоторые файлы, — для этого придётся вызывать scp или sftp вместо ssh, к которому применён ваш alias. 

Чтобы решить ту же проблему (различные типы при подключении к серверу crunch) с помощью конфигурационного файла, вы можете настроить его следующим образом:

Host crunch
  Hostname crunch.example.com
  Port 2222
  IdentityFile /home/user/.id_c

Поместив эти строки в ~/.ssh/config и выполнив команду, которая читает ssh crunch, вы обнаружите, что две необходимые опции применяются к сеансу автоматически и с правильным именем хоста, определённым через DNS. scp и sftp также подхватят их — и есть даже некоторые сторонние инструменты, которые либо используют эти утилиты под капотом, либо интерпретируют файл конфигурации SSH самостоятельно, чтобы обеспечить тот же набор функций и соглашений без дополнительных усилий.

Как мы видим, конфигурационный файл можно использовать как alias, особенно для длинного имени хоста. Системные администраторы могут использовать общесистемный файл /etc/ssh/ssh_config для настройки сессий, которые они хотели бы предоставлять для своих пользователей, тем самым контролируя доступные сессии.

Escape sequences (Управляющая последовательность)

Есть несколько хитрых нюансов при работе в терминале во время установленной ssh-сессии с удалённым хостом. Например, нажатие [Ctrl] + [z] на клавиатуре переведёт в фоновый режим не локальный терминал ssh, соединяющий вас с удалённым хостом, а любой процесс, запущенный на переднем плане на удалённой стороне сеанса SSH. Та же история с [Ctrl] + [c], которая прозрачно пройдёт через ssh и вместо этого передаст сигнал SIGINT процессу на удалённой стороне.

Это имеет как преимущества, так и недостатки: вы можете использовать большинство удаленно выполняемых программ и инструментов практически так же, как если бы они были запущены локально. Но если что-то пойдёт не так, то вы можете потерять соединение ssh-сессии. 

При выполнение определённой комбинации можно запустить процесс ssh, зависимый от протокола внутрисетевого взаимодействия. Это позволяет пользователю взаимодействовать с ним, хотя и ограниченным образом. По умолчанию процесс активизируется, когда пользователь вводит комбинацию из перевода строки (т.е. нажимает [Enter]) и тильды ([~]).

Следующее нажатие клавиши сразу после этой магической последовательности имеет важное значение: оно может, например, завершить ту самую сессию, которую вы используете в данный момент. Чтобы узнать о своих возможностях, нажмите клавишу [?].

Чтобы понять, что такое escape sequences и как их использовать, если (или, скорее, когда) они вам понадобятся, лучше всего поиграть с ними в сессии, которую вы инициируете специально для экспериментов.

RemoteForward и LocalForward

SSH можно использовать для туннелирования сетевого трафика между узлами вашей локальной и удаленной сети сервера SSH. Этот туннель будет обладать всеми теми же свойствами, что и сам сеанс SSH: трафик между вашим локальным узлом и удаленным узлом SSH-сервера шифруется и происходит внутри того же TCP-соединения, которое также обрабатывает ваш интерактивный сеанс (если таковой существует, поскольку вы также можете использовать SSHv2 для пересылки только сеансов).

Два самых важных и полезных свойства этих двух функций: простота настройки и тот факт, что SSH используется повсеместно. Если у вас есть возможность подключения по SSH и терминальная оболочка на удаленной стороне, то, скорее всего, вы сможете найти способ позволить ресурсам в обеих сетях общаться друг с другом, но это потребует некоторого опыта в настройке.

Чтобы показать простой пример начала работы, предположим, что вы вошли на локальный хост, который находится в собственной локальной сети, с сервером, к которому он может обратиться по адресу mynas.lan, и на котором запущен sshd, привязанный к TCP-порту 22. Опираясь на предыдущий пример, мы хотим разрешить другим пользователям хоста crunch подключаться к процессу SSH-сервера на mynas.lan (например, для доступа к ресурсам на этом конкретном хосте). Для этого мы должны выполнить команду: ssh -R1337:mynas.lan:22 crunch которая после аутентификации переведёт нас в оболочку входа на хост crunch.

Но сессия SSH, которая привела нас туда, также установила прослушивающий сокет на TCP-порту 1337 на crunch (по умолчанию, только для адресов, настроенных на его loopback-интерфейсе), и будет перетягивать весь трафик, поступающий туда, в туннель, который ssh создал благодаря параметру -R нашего переключателя. Весь этот трафик пройдёт через туннель на другую сторону SSH-сессии и будет передан на mynas.lan:22 по TCP в локальную сеть, откуда была отправлена ваша команда ssh. Обратите внимание, что для того, чтобы это сработало, crunch не нужно знать о mynas. lan — это конкретное имя хоста будет использоваться только локальной частью SSH-сессии, которая указала его в параметре -R.

Ключ -L работает почти наоборот: он может туннелировать сетевой ресурс на удалённой стороне сессии (т.е. что-то в сети, к чему crunch может подключиться и воспринимает его как локальный в своей собственной сети) в локальную сеть и таким образом открывать его для локальных пользователей. То есть команда ssh -L9876:coolstuff.local:23 crunch заставит TCP-порт 9876 локального хоста передавать трафик по зашифрованному SSH-туннелю в crunch, а там передавать его хосту, идентифицированному в (локальном DNS crunch) как coolstuff.local, нацеливаясь на его TCP-порт 23. С хоста, инициировавшего процесс ssh, вы могли бы пообщаться по telnet с coolstuff.local.

Чтобы узнать больше о тонкостях -L и -R, лучше всего прочитать соответствующую документацию в ssh_config(5). Обратите внимание на LocalForward и RemoteForward. (Это ключевые слова, которые вы будете использовать для постоянного создания этих типов переадресаций в ~/.ssh/config). Вы увидите, что необязательно всегда привязывать прослушивающий сокет к интерфейсу loopback (если конфигурация sshd удаленного компьютера позволяет это сделать).

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

DynamicForward

И LocalForward, и RemoteForward — полезные функции, но они могут вести только к одному виду конечных. Для некоторых случаев использования, конечно, было бы неплохо получить некоторую гибкость, и DynamicForward обеспечивает это: 

Если вы подключитесь к нашему старому другу crunch через ssh -D1234 crunch, это заставит локальный процесс ssh установить прослушивающий сокет на TCP-порту 1234 (привязанный к адресам интерфейса loopback). TCP-трафик, приходящий туда и соответствующий протоколу проксирования SOCKS5, будет передан по зашифрованной линии на удаленную сторону SSH-сессии, запущенной на crunch, и смело отправится туда, куда скажет ему магия SOCKS-прокси. Если у вас есть приложение на локальной машине, которое может быть настроено на использование SOCKS-прокси, направьте его на localhost:1234, и его трафик «телепортируется» через туннель SSH DynamicForward на crunch.

Чтобы использовать эту возможность в примере с curl, откройте второй shell на вашем локальном хосте (с открытой SSH-сессией, в которой было указано -D1234), и запустите командную строку, начинающуюся с curl --preproxy socks5://localhost:1234 ..., добавив URL по вашему выбору. Это заставит curl проксировать своё TCP-соединение через SOCKS5 proxy listener, который ssh-запрос DynamicForward создал ранее, и заставит весь трафик curl, прибывающий в конечный пункт назначения, выглядеть и ощущаться так, как будто он пришёл из crunch. Следовательно, этот трафик будет подчиняться любым сетевым условиям crunch, правилам брандмауэра и т. д., что, вероятно, приведёт к другому набору возможностей и ограничений, чем те, которые применяются к вашему локальному хосту.

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

ControlMaster

Окей, здесь все становится немного забавным. Да, ControlMaster не для слабонервных, но это настолько полезная функция для частых случаев использования, что я не могу оставить ее без упоминания.

SSH показывает относительно низкую производительность, когда вы используете его для создания множества недолговечных сессий и выполняете небольшое количество операций в каждой из них. Популярные инструменты конфигурации, такие как ansible, виновны в таком поведении, и есть различные возможности оптимизации, чтобы сделать создание сеанса SSH быстрее (как, например, переход с ключей RSA на ecdsa или ed25519). Правильная настройка режима ControlMaster, конечно, значительно превосходит любые другие способы настройки, которые вы можете придумать, но также имеет долю недостатков.

Давайте рассмотрим это более подробнее.

A persistent SSH connection socket per remote host

Включение ControlMaster переводит ssh в принципиально иной режим работы: вместо того, чтобы каждый новый процесс ssh самостоятельно устанавливал TCP-соединение с удалённым узлом, первый процесс, у которого настроен подходящий ControlPath, позаботится об этом и создаст (UDS) прослушивающий сокет по пути, указанному ControlPath. Последующие подключения к тому же удалённому узлу, которые разделяют ControlPath с этим экземпляром, будут сначала подключаться к этому локальному прослушивающему сокету и создавать ещё один параллельный SSH сеанс через TCP/SSH соединение, которое уже было установлено первым процессом ssh для успешного подключения. 

Это позволит обойти трёхстороннее рукопожатие TCP для нового соединения на четвёртом уровне OSI, а также пропустить аутентификацию SSH на седьмом уровне OSI, что позволяет сократить два наиболее трудоёмких и вызывающих задержку этапа, через которые должно пройти новое соединение SSH в нормальных условиях.

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

Учитывая тот факт, что в одном соединении может быть множество дополнительных параллельно активных сессий, завершение одного «неправильного» PID может иметь довольно неприятные последствия для приложений или задач, выполняющихся на этом удалённом хосте. Можно использовать ControlPersist для борьбы с этой конкретной проблемой, но наличие современного Linux-хоста на базе systemd без настроенной задержки сеанса systemd-logind все равно может превратить ваш начальный процесс ssh в бомбу замедленного действия, которая, взорвавшись, может унести с собой других. Так что будьте осторожны.

А если первая сессия в интерактивном режиме, то подключенные к сокету ControlMaster другие процессы будут препятствовать нормальному завершению начального процесса/сессии после завершения интерактивной части оболочки. Процесс ssh будет как бы «висеть», ожидая завершения работы других пользователей его средств, подобно тому, как интерактивные сессии с настроенными переадресациями (и активно используемые) завершают свою терминальную сессию. Опять же, это облегчается с помощью ControlPersist, но при этом действуют упомянутые выше условия.

Кроме того, любой пользователь, имеющий доступ к установленному на ControlPath в файловой системе сокету ControlMaster, также сможет подключиться к общей сессии. Это немного похоже на сценарий «перенаправление агента на неавторизованный хост», но потенциально хуже, поскольку атакующему даже не нужно иметь информацию о том, для каких именно устройств действуют идентификаторы агента.

Тест-драйв ControlMaster

Чтобы поиграться с этой функцией, одновременно откройте два сеанса оболочки. Настройте конфигурационную строку SSH как в следующем примере, относительно вашей среды:

Host cmaster-test
  Hostname replace-with-actual-remote.example.com
  BatchMode yes
  ControlMaster auto
  ControlPath ~/. ssh/cmaster-test-do-not-use-this-in-production
  # ControlPersist yes # also try to toggle this!

Теперь подключитесь к хосту, используя ssh cmaster-test в обеих оболочках. Обратите внимание, что вторая сессия будет запускаться заметно быстрее (и, возможно, пропустит отображение motd). Попробуйте завершить первый сеанс SSH, выйдя из системы, и посмотрите, что произойдёт со вторым. Затем создайте третий и подключитесь снова. Повторите все с помощью ControlPersist. Убейте несколько ssh-процессов друг под другом, просто чтобы подурачиться.

Подводя итог, можно сказать, что установка ControlMaster и ControlPath как включенных по умолчанию является плохой идеей. Но с учётом его уникальных преимуществ в производительности, он является настоящим удовольствием для хостов, настроенных в инвентаре ansible. Если правильно распределить правила в конфигурации ansible и в пользовательском файле ~/.ssh/config, вы сможете получить лучшее из возможного, повторно используя постоянные сокеты ControlMaster в сценариях, где это имеет смысл, и оставив его в покое в тех случаях, когда вы считаете, что это скорее риск, чем польза.  

Это может потребовать кучу времени, ведь придётся многое перепробовать, чтобы сделать все правильно. Так что думайте сами, решайте сами. Если вам понравится этот опыт, ознакомьтесь с документацией ssh_config(5) по ControlPath и убедитесь, что эти сокеты попадают в частный, защищенный каталог, доступ к которому могут получить только авторизованные учетные записи.

ProxyJump and ProxyCommand

Часто корпоративные политики безопасности (или просто меры предосторожности) заставляют использовать «бастионы» хостов — разрыв в протоколе, к которому пользователь должен подключиться с помощью SSH, а затем использовать этот бастионный хост в качестве источника соединения с реальным местом назначения, куда пользователь намеревается попасть. При правильной реализации это может действительно укрепить безопасность вашей организации. С другой стороны, это делает подключение к предполагаемому удалённому узлу сложным, и может сломать scp, sftp и другие полезные штуки.

ProxyJump может помочь вам справиться с подобными настройками и перепрыгнуть через (теоретически) произвольное количество цепочек SSH-переходов между вашим локальным узлом и предполагаемым удалённым. Эта опция вызовет «предварительное» SSH-соединение с узлом ProxyJump, а затем использует возможности протокола SSH сервера этого узла для создания переадресации на SSH-сервер-приемник адресата. Конечно, если конфигурация SSH-сервера узла бастиона не позволяет создавать переадресации, это не поможет.

Ранее OpenSSH ProxyJump не был доступен, но его можно было воспроизвести с помощью умного использования опции ProxyCommand и некоторой магии netcat/socat. Сегодня вы должны отдавать предпочтение ProxyJump, если хотите добраться до конечного хоста за один прыжок. 

Если бы я знал об этой возможности в 2007 году на одной из своих первых работ, я бы избавил себя от многих хлопот, реализуя фреймворк для обёртки ssh-соединений в виде bash-скрипта, настолько ужасного, что от него хотелось выколоть себе глаза.

Спасибо, что нашли время прочитать эту статью. Надеюсь, она была интересной. Я также готов раскрыть тему дальше.

что это такое? Как использовать SSH туннелирование для безопасного серфинга?

Существует три различных типа туннелирования, и все они используются для решения разных задач. Каждая задача предполагает использование SSH-сервера для перенаправления трафика из одного сетевого порта в другой. Трафик передается по зашифрованному SSH-соединению, поэтому его нельзя отследить или изменить в процессе передачи:

Туннелирование можно реализовать с помощью ssh-команды в Linux, Mac OS и операционных системах семейства UNIX. Для пользователей Windows, где нет встроенной ssh-команды, мы предлагаем бесплатный инструмент PuTTY. Он умеет подключаться к SSH-серверам. Он также поддерживает SSH-туннелирование.

  • Локальное перенаправление портов (SSH port forwarding): получаем доступ по SSH к удалённым ресурсам на локальной системе
  • Дистанционное перенаправление портов: открываем доступ к локальным ресурсам на удалённой системе
  • Динамическое перенаправление портов: используем SSH-сервер в качестве прокси

«Локальное перенаправление портов» позволяет осуществлять доступ к ресурсам, находящимся внутри локальной сети. Предположим, что нужно попасть на офисный сервер БД, сидя дома. В целях безопасности этот сервер настроен так, чтобы принимать подключения только с ПК, находящихся в локальной сети офиса. Но если у вас есть доступ к SSH-серверу, находящемуся в офисе, и этот SSH-сервер разрешает подключения из-за пределов офисной сети, то к нему можно подключиться из дома. Затем осуществить доступ к БД. Проще защитить от атак один SSH-сервер, чем защищать каждый ресурс локальной сети по отдельности.

Чтобы сделать это, вы устанавливаете SSH-соединение с SSH-сервером и говорите клиенту передать трафик с указанного порта на локальном ПК. Например, с порта 1234 на адрес сервера базы данных и его порт внутри офисной сети. Когда вы пытаетесь получить доступ к БД через порт 1234 на вашем ПК («localhost») трафик автоматически «туннелируется» по SSH-соединению и отправляется на сервер БД.

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

Чтобы использовать локальное перенаправление, подключитесь к SSH-серверу с использованием вспомогательного аргумента -L. Синтаксис для туннелирования трафика будет следующим:

ssh -L local_port:remote_address:remote_port [email protected]

Предположим, что офисный сервер находится по адресу 192.168.1.111. У вас есть доступ к SSH-серверу через адрес ssh.youroffice.com, и имя вашего аккаунта на SSH-сервере — bob. В таком случае необходимая команда будет выглядеть следующим образом:

ssh -L 8888:192. 168.1.111:1234 [email protected]

Запустив эту команду, вы попадете на офисный сервер баз данных через порт 8888 на localhost. Если у СУБД есть веб-интерфейс, можно вписать в адресную строку браузера http://localhost:8888. Если у вас инструмент командной строки, которому необходим сетевой адрес базы данных, то направьте его на localhost:8888. Весь трафик, отправленный на порт 8888 на ПК, будет перенаправлен на 192.168.1.111:1234 внутри офисной сети:

Это слегка сбивает с толку, если надо подключиться к серверному приложению, запущенному в той же системе, где и сам SSH-сервер. К примеру, есть SSH-сервер, работающий на порте 22 на офисном ПК. Но у вас также есть сервер баз данных, работающий на порте 1234 в той же системе по тому же адресу. Вам нужно подключиться к БД из дома, но система принимает только подключение через SSH (через 22 порт), и сетевой экран не пропускает любые внешние подключения. В таком случае можно запустить следующую команду:

ssh -L 8888:localhost:1234 bob@ssh. youroffice.com

При попытке подключиться к БД через 8888 порт на вашем ПК, трафик будет передаваться с помощью SSH-подключения. Когда он достигнет системы, в которой работает SSH, SSH-сервер отправит его на порт 1234 на «localhost», принадлежащий тому же ПК, на котором запущен SSH-сервер. То есть, «localhost» в приведённой выше команде означает «localhost» с перспективы удалённого сервера:

Чтобы сделать это в PuTTY на Windows, выберите опцию Connection > SSH > Tunnels. Далее опцию «Local». В поле «Source Port» укажите локальный порт. В поле «Destination» введите целевой адрес и порт в формате удалённый_адрес:удалённый_порт.

Например, если нужно настроить SSH-тоннель, как это сделано выше, то введите 8888 в качестве порта-источника и localhost:1234 в качестве целевого адреса. После этого нажмите «Add» и затем «Open», чтобы открыть SSH-подключение. До подключения SSH туннелирования нужно ввести адрес и порт самого SSH-сервера в разделе «Session»:

«Дистанционное перенаправление портов» — ситуация, противоположная локальному перенаправлению, и используется не так часто. Она позволяет открывать доступ к ресурсам на локальном ПК через SSH-сервер. Предположим, что на локальном ПК настроен веб-сервер. Но ваш ПК защищён сетевым экраном, который не пропускает входящий трафик на сервер.

Если есть доступ к удалённому SSH-серверу, можно подключиться к этому SSH-серверу и использовать дистанционное перенаправление портов. Ваш SSH-клиент укажет серверу перенаправлять трафик с определённого порта – скажем, 1234 – на SSH-сервере на указанный адрес и порт на вашем ПК или внутри локальной сети. Когда кто-то подключается к порту 1234 на SSH-сервере, этот трафик автоматически «туннелируется» по SSH-соединению. Любой, кто подключается к SSH-серверу, сможет получить доступ к серверу, запущенному на вашем ПК. Это достаточно эффективный способ обхода фаерволов.

Чтобы воспользоваться дистанционным туннелированием IP, используйте ssh-команду с аргументом -R. Синтаксис здесь будет практически таким же, как и в случае с локальным перенаправлением:

ssh -R remote_port:local_address:local_port username@server. com

Предположим, что нужно создать серверное приложение, прослушивающее порт 1234 на вашем ПК. Оно доступно через порт 8888 на удалённом SSH-сервере. Адрес SSH-сервера ssh.youroffice.com, а ваше имя пользователя на SSH-сервере bob. Значит, команда будет следующей:

ssh -R 8888:localhost:1234 [email protected]

Затем кто-то может подключиться к SSH-серверу через порт 8888, и это подключение будет туннелировано на серверное приложение, запущенное на порте 1234 ПК, с которого вы подключались:

Чтобы сделать это в PuTTY для Windows, выберите опцию Connection > SSH > Tunnels. Далее – опцию «Remote». В поле «Source Port» укажите удалённый порт. В поле «Destination» введите целевой адрес и порт в формате локальный_адрес:локальный_порт.

Например, если нужно настроить SSH-тоннель, как это сделано выше, то укажите 8888 в качестве порта-источника и localhost:1234 в качестве целевого адреса. После этого нажмите «Add» и затем «Open», чтобы открыть SSH-подключение. До подключения нужно будет ввести адрес и порт самого SSH-сервера в разделе «Session».

После этого пользователи смогут подключаться к порту 8888 на SSH-сервере и их трафик будет передаваться на порт 1234 на вашей локальной системе:

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

Нужно включить опцию «GatewayPorts» в sshd_config на удалённом SSH-сервере, если хотите изменить эти настройки.

Также существует «динамическое перенаправление портов», которое работает по тому же принципу что прокси или VPN-сервер. SSH-клиент создаёт SOCKS-прокси, который можно настраивать под собственные приложения. Весь трафик, отправляемый через прокси, будет отправляться через SSH-сервер. Принцип здесь схож с локальным перенаправлением – берётся локальный трафик, отправленный на определённый порт на вашем ПК, и перенаправляется через SSH-соединение на удалённый адрес.

Предположим, что вы используете общедоступную Wi-Fi сеть. Но хочется делать это безопасно. Если у вас есть доступ к SSH-серверу из дома, то можно подключиться к нему и использовать динамическое перенаправление. SSH-клиент создаст SOCKS-прокси на вашем ПК. Весь трафик, отправленный на этот прокси, будет отправляться через подключение к SSH-серверу. Никто из тех, кто использует общедоступную Wi-Fi сеть, не сможет отслеживать ваши перемещения в сети или закрывать доступ к сайтам. С перспективы сайтов, которые посещаете, будет казаться, что вы заходите на них с домашнего ПК.

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

Например, если медиа-сервер находится по адресу 192.168.1.123 в вашей домашней сети, то можно добавить адрес 192.168.1.123 в любое приложение при помощи SOCKS-прокси и получить доступ к медиа-серверу, как будто вы находитесь внутри домашней сети.

Чтобы воспользоваться динамическим перенаправлением, запустите ssh-команду с аргументом -D:

ssh -D local_port [email protected]

Предположим, что у вас есть доступ к SSH-серверу по адресу ssh.yourhome.com, а ваш логин на SSH-сервере – bob. Нужно использовать динамическое перенаправление для того, чтобы открыть SOCKS-прокси по порту 8888 на текущем ПК. Тогда команда для SSH туннелирования будет выглядеть следующим образом:

ssh -D 8888 [email protected]

После этого можно настроить браузер или другое приложение на использование локального IP-адреса (127.0.0.1) и порта 8888. Весь трафик этого приложения будет перенаправляться через туннель:

Чтобы сделать это в PuTTY для Windows, выберите опцию Connection > SSH > Tunnels. Далее – опцию «Dynamic». В поле «Source Port» укажите локальный порт.

Например, если вам нужно настроить SOCKS-прокси на порт 8888, то введите 8888 в качестве порта-источника. После этого нажмите «Add» и затем «Open», чтобы открыть SSH-подключение.

После этого можно настроить приложение на подключение через SOCKS-прокси на вашем локальном ПК (то есть, по IP-адресу 127.0.0.1, который ведёт на ваш локальный ПК) и указать корректный порт для работы:

К примеру, можно настроить браузер Firefox на использование SOCKS-прокси. Это удобно, так как у Firefox могут быть отдельные настройки прокси, и поэтому не обязательно использовать базовые параметры для всей системы. Firefox будет отправлять трафик через SSH туннелирование, а другие приложения будут использовать интернет-подключение в обычном режиме.

Туннель будет оставаться активным и открытым до тех пор, пока открыта сессия SSH-соединения. Когда вы завершите SSH-сессию и отключаетесь от сервера, туннель тоже закроется. Чтобы снова открыть туннель, переподключитесь при помощи соответствующей команды или нужной функции в PuTTY.

Пожалуйста, оставьте ваши отзывы по текущей теме статьи. Мы крайне благодарны вам за ваши комментарии, отклики, лайки, подписки, дизлайки!

Пожалуйста, оставляйте ваши мнения по текущей теме статьи. За комментарии, дизлайки, подписки, отклики, лайки низкий вам поклон!

Пожалуйста, оставляйте свои комментарии по текущей теме материала. Мы крайне благодарны вам за ваши комментарии, отклики, подписки, лайки, дизлайки!

Валентин Сейидовавтор-переводчик

Как обслуживать запрос типа «localhost:1234/Admin/Product/List» из плагина?

  • Главная >
  • Форумы >
  • org/ListItem»> Общие >
  • Разработка >
  • Как обслуживать запрос вида «localhost:1234/Admin/Product/List» из плагина?

Эта тема была автоматически закрыта через 365 дней после последнего ответа. Новые ответы больше не допускаются.

Привет!!!
Я работаю над Nop 2.65. Мне нужно добавить два поля на уровне продукта и использовать их на уровне заказа.
Итак, каковы наилучшие методы реализации этого…? Я пытаюсь реализовать это, используя отдельный плагин, но сталкиваюсь с некоторыми трудностями.
  
Как обслужить запрос типа «localhost:1234/Admin/Product/List» из плагина? (означает все запросы относительно продукта, такого как добавление/обновление продукта на стороне администратора

Дхармик написал:

Привет!!!
Я работаю над Nop 2. 65. Мне нужно добавить два поля на уровне продукта, и я буду использовать его на уровень заказа.
Итак, каковы наилучшие методы реализации этого…? Я пытаюсь реализовать это, используя отдельный плагин, но сталкиваюсь с некоторыми трудностями.
  
Как обслужить запрос вида «localhost:1234/Admin/Product/List» из плагина? (означает все запросы относительно продукта, такого как добавление/обновление продукта на стороне администратора

. Для этого вы можете использовать ActionFilter. ActionFilter позволяет запускать коды до/после выполнения действия, и я часто использовал его в своем плагине. 😀

wooncherk написал:


Для этого можно использовать ActionFilter.ActionFilter позволяет запускать коды до/после выполнения Action, и я часто использовал его в своем плагине. 😀

Здравствуйте, у меня возникла та же проблема при реализации этого типа настройки. Итак, не могли бы вы дать нам демо для фильтра действий. Как это работает? И, если возможно, не могли бы вы предоставить нам демо-код или плагин, который вы написали с помощью фильтра действий?

Заранее спасибо.

krutal написал:

Вы можете использовать ActionFilter для этого. ActionFilter позволяет запускать коды до/после выполнения Action, и я часто использовал его в своем плагине. 😀

Здравствуйте, у меня такая же проблема с реализацией этого типа настройки. Итак, не могли бы вы дать нам демо для фильтра действий. Как это работает? И, если возможно, не могли бы вы предоставить нам демо-код или плагин, который вы написали с помощью фильтра действий?

Заранее спасибо.

Фильтр действий — это концепция MVC, поэтому вам просто нужно выполнить поиск в Интернете, и вы найдете массу информации об этом.

В любом случае, если вам нужен стартер, я кратко описал фильтр действий здесь:

https://www.nopcommerce.com/boards/t/19724/how-to-load-cshtml-file-from-plugin. aspx

Спасибо.

Я только запускаю фильтр действий. И попробовал ссылку, которую вы мне дали.

Но я просто не мог понять код ниже.

 if (actionDescriptor.ControllerDescriptor.ControllerType == typeof(OrderController) && 
                 actionDescriptor.ActionName.Equals("AddProductToOrderDetails") && 
                       
               90pOSTpContext.HttpContext.Reodquest.0019             { 
                 return new Filter[] 
                 { 
                     new Filter(_actionFilter, Filter Scope.Action, null) 9      } 
             }

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

Заранее спасибо.

krutal написал(а):

Спасибо.

Я только запускаю фильтр действий. И попробовал ссылку, которую вы мне дали.

Но я просто не мог понять код ниже.

 if (actiondescriptor. controllerdescriptor.controllertype == typeof (ordercontroller) && 
 actiondescriptor.actionname.equals ("AddProductToorderDetails") && 
 ConterlerContext.httpContext.Request.htttpmethpmethtpmethpmethtpmethpmethpmothpmothpmethpmoth. 
                 { 
                    новый фильтр (_actionFilter, FilterScope.Action, null) 
                  }; 
             }

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

Заранее спасибо.

Вы хотите применить фильтр только к определенному контроллеру, конкретному действию и конкретному методу HTTP. 😀

Эта тема была автоматически закрыта через 365 дней после последнего ответа. Новые ответы больше не допускаются.

Соединение WebSocket с ‘ws://localhost:1234/tiptap’ не удалось: Ошибка при установлении соединения: net::ERR_CONNECTION_REFUSED

marcoippolito

#1

Я пытаюсь понять, как использовать локальный сервер веб-сокетов.

Чтобы использовать локальный сервер веб-сокетов, я изменил WebSocketProvider в https://github.com/yjs/yjs-demos/blob/master/tiptap/src/Realtime.js следующим образом:

 //const provider = new WebsocketProvider('wss://demos.yjs.dev', 'tiptap', ydoc)
const provider = новый WebsocketProvider('ws://localhost:1234', 'tiptap', ydoc)

Но в консоли браузера я получаю это сообщение об ошибке:

Сбой подключения WebSocket к ‘ws://localhost:1234/tiptap’: Ошибка при установлении соединения: net::ERR_CONNECTION_REFUSED

Как решить проблему?
С нетерпением жду вашей помощи.
Марко

Канадуан

#2

Вы используете сервер y-websocket локально? например

 ПОРТ = 1234 npx y-websocket-сервер

маркоипполито

#3

@canadaduane Это была моя ошибка!!! Я не запускал сервер y-websocket локально…)))

 (база) marco@pc01:~/webMatters/vueMatters/yjs-demos/tiptap$ PORT=1234 npx y-websocket-server

работает на порту 1234

У меня все работает!

Спасибо. И простите за эту ошибку

canadaduane

#4

Рад, что все заработало!

1 Нравится

маркоипполито

#5

@canadaduane Привет, Дуэйн!
Сейчас я пытаюсь сделать следующий шаг.
Даже если мое приложение будет развернуто в облаке, в данный момент я разрабатываю его на локальном ПК.
Просто чтобы понять, как заставить его работать правильно, я попытался использовать Realtime.js как есть, с
const provider = new WebsocketProvider(‘ws://localhost:1234’, ‘tiptap’, ydoc)

В конфигурации веб-сервера nginx я поместил эту часть для веб-сокета:

 map $http_upgrade $connection_upgrade {
  обновление по умолчанию;
  '' Закрыть;
}
восходящий веб-сокет {
    сервер ggc.world:1234;
}
сервер {
    слушать 8443 ssl;
    имя_сервера ggc.world;
    ssl_certificate /etc/letsencrypt/live/ggc.world-0002/fullchain.pem; # под управлением Certbot
    ssl_certificate_key /etc/letsencrypt/live/ggc.world-0002/privkey.pem; # под управлением Certbot
    ssl_trusted_certificate /etc/letsencrypt/live/ggc.world-0002/chain.pem;
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # под управлением Certbot
    расположение / {
        прокси_пасс http://вебсокет;
        прокси_http_версия 1. 1;
        proxy_set_header Обновить $http_upgrade;
        proxy_set_header Соединение $connection_upgrade;
        proxy_set_header Хост $host;
    }
}

Я запускаю y-websocket-server локально:

 (базовый) marco@pc01:~/webMatters/vueMatters/GGC$ PORT=1234 npx y-websocket-server
работает на порту 1234

При запуске приложения я получаю эту ошибку:

Ошибка подключения WebSocket к ‘wss://localhost:1234/tiptap’: Ошибка при установлении соединения: nett::ERR_SSL_PROTOCOL_ERROR

Я пытался изменить конфигурацию nginx:

 восходящий веб-сокет {
    #сервер ggc.world:1234;
    сервер 127.0.0.1:1234;
}
сервер {
    слушать 8443 ssl;
    имя_сервера ggc.world;

Но опять же:
«Подключение WebSocket к ‘wss://localhost: 1234/tiptap’failed: Ошибка при установлении соединения: net::ERR_SSL_PROTOCOL_ERROR»

Если nginx прослушивает порт 8443 для ssl, должен ли я поместить его куда-нибудь в Realtime.js ?
Как заставить это работать?

канададуан

#6

Вот моя конфигурация nginx. У меня есть собственный y-websocker-сервер, работающий на порту 1235 (см. код):

 сервер {
слушать 80 ;
# слушать [::]:80 ipv6only=on;
корень /var/www/html;
индекс index.php index.html index.htm;
имя_сервера y.relm.us;
расположение / {
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Хост $host;
прокси_пароль http://localhost:1235;
прокси_http_версия 1.1;
proxy_set_header Обновить $http_upgrade;
proxy_set_header Соединение "Обновление";
proxy_connect_timeout 7 дней;
proxy_send_timeout 7 дней;
proxy_read_timeout 7 дней;
client_max_body_size 2м;
}
error_page 413 @filetoobig;
страница_ошибки 404 /404.html;
error_page 500 502 503 504 /50x.html;
местоположение = /50x.html {
корень /usr/share/nginx/html;
}
местоположение @filetoobig {
add_header Access-Control-Allow-Origin * всегда;
}
    слушать 443 ssl; # под управлением Certbot
    ssl_certificate /etc/letsencrypt/live/y. relm.us/fullchain.pem; # под управлением Certbot
    ssl_certificate_key /etc/letsencrypt/live/y.relm.us/privkey.pem; # под управлением Certbot
    включить /etc/letsencrypt/options-ssl-nginx.conf; # под управлением Certbot
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # под управлением Certbot
}

Использование GDB — документация QEMU 7.1.50

QEMU поддерживает работу с gdb через средство удаленного подключения gdb («gdbstub»). Это позволяет отлаживать гостевой код в том же так, как вы могли бы с помощью средства отладки низкого уровня, такого как JTAG на реальном оборудовании. Вы можете остановить и запустить виртуальную машину, проверять состояние, такое как регистры и память, и устанавливать точки останова и точки наблюдения.

Чтобы использовать gdb, запустите QEMU с параметрами -s и -S . 9Опция 0140 -s заставит QEMU прослушивать входящие соединения. из gdb на TCP-порт 1234, а -S заставит QEMU не запускать guest, пока вы не скажете об этом из gdb. (Если вы хотите указать, какой TCP-порт для использования или для использования чего-то другого, кроме TCP, для gdbstub соединения используйте параметр -gdb dev вместо -s . Видеть Например, используя сокеты unix.)

qemu-system-x86_64 -s -S -kernel bzImage -hda rootdisk.img -append "root=/dev/hda"

QEMU запустится, но будет молча ждать подключения gdb.

Затем запустите gdb в исполняемом файле vmlinux:

 > gdb vmlinux

В gdb подключитесь к QEMU:

 (gdb) целевой удаленный локальный хост: 1234

После этого вы можете нормально использовать gdb. Например, введите «c», чтобы запустить ядро:

 (gdb) c

Вот несколько полезных советов по использованию gdb в системном коде:

  1. Используйте info reg для отображения всех регистров ЦП.
  2. Используйте x/10i $eip для отображения кода в позиции ПК.
  3. Используйте набор архитектуры i8086 для создания дампа 16-битного кода. Затем используйте x/10i $cs*16+$eip для сброса кода в позиции ПК.

Отладка многоядерных машин

Абстракция GDB для отладки целей с несколькими возможными параллельные потоки исполнения являются двухуровневыми: они поддерживают несколько «низших», каждый из которых может иметь несколько «потоков». Когда QEMU машина имеет более одного ЦП, QEMU представляет каждый кластер ЦП как отдельный «низший», где каждый ЦП в кластере является отдельным «нить». Большинство типов машин QEMU имеют одинаковые ЦП, поэтому один кластер, в котором есть все процессоры. Несколько типов машин неоднородны и имеют несколько кластеров: например, sifive_u машина имеет кластер с одним ядром E51 и второй кластер с четырьмя ядра U54. Здесь Е51 единственная резьба в первой низшей, а ядра U54 — все потоки во втором подчиненном.

Когда вы подключаете gdb к gdbstub, он автоматически подключиться к первому подчиненному; вы можете отображать процессоры в этом кластера с помощью команды gdb info thread и переключаться между их с помощью обычных команд управления потоками gdb.

Для многокластерных машин, к сожалению, gdb по умолчанию не обрабатывать несколько подчиненных, поэтому вам нужно явно подключить им. Во-первых, вы должны подключиться к расширенный-дистанционный протокол, не удаленный :

 (gdb) цель расширенный удаленный локальный хост: 1234

После подключения gdb будет иметь один подчиненный для первый кластер. Вам нужно создать подчиненных для других кластеры и присоединяйтесь к ним, например:

 (gdb) add-inferior
Добавлен низший 2
(gdb) низший 2
[Переключение на нижний 2 [] ()]
(gdb) прикрепить 2
Присоединение к процессу 2
предупреждение: исполняемый файл не указан, и цель не поддерживает
автоматическое определение исполняемого файла. Попробуйте использовать команду «файл».
0x00000000 в ?? ()

Как только вы это сделаете, информационных потоков будут показывать процессоры в все кластеры, к которым вы присоединились:

 (gdb) информационные потоки
  Идентификатор целевого идентификатора кадра
  1. 1 Thread 1.1 (процессор cortex-m33-arm-cpu [работает]) 0x00000000 в ?? ()
* 2.1 Thread 2.2 (процессор cortex-m33-arm-cpu [остановлен]) 0x00000000 в ?? ()

Вероятно, вы также захотите установить gdb в режим schedule-multiple , так что, когда вы говорите gdb continue , он возобновляет работу всех процессоров, не только в кластере, над которым вы сейчас работаете:

 (gdb) установить несколько расписаний на

Использование сокетов unix

Альтернативным методом подключения gdb к QEMU gdbstub является использование сокет unix (если поддерживается вашей операционной системой). Это полезно, когда запуск нескольких тестов параллельно, или если у вас нет известного свободного TCP порт (например, при запуске автоматических тестов).

Сначала создайте chardev с соответствующими параметрами, затем указать gdbserver использовать это устройство:

qemu-system-x86_64 -chardev socket,path=/tmp/gdb-socket,server=on,wait=off,id=gdb0 -gdb chardev:gdb0 -S . ..

Запустите gdb, как и раньше, но на этот раз подключитесь, используя путь к сокет:

 (gdb) целевой удаленный /tmp/gdb-socket

Обратите внимание, что для использования сокета unix для подключения вам потребуется gdb версии 9.0 или новее.

Дополнительные параметры отладки

Проверка физической памяти

Еще одна функция QEMU gdbstub — переключение памяти GDB работает, по умолчанию GDB покажет текущую память процесса с учетом трансляция виртуального адреса.

Если вы хотите проверить/изменить физическую память, вы можете установить gdbstub работать с физической памятью, а не с виртуальной.

Режим памяти можно проверить, отправив следующую команду:

пакет обслуживания qqemu.PhyMemMode
Будет возвращено либо 0, либо 1, 1 означает, что вы в данный момент находитесь в Режим физической памяти.
пакет обслуживания Qqemu.PhyMemMode:1
Это изменит режим памяти на физическую память.

No related posts.