Подключение к пирам бесконечно: «Почему может не работать торрент? Показывает «Подключение к пирам»

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

1. Нажмите Ctrl + P , чтобы открыть Настройки (Если эта опция не работает для вас, щелкните Option в верхнем левом углу и выберите Preferences)
2. Теперь нажмите Connection в вертикальном меню
3. Убедитесь, что Включить сопоставление портов UPnP и Включить сопоставление портов NAT-PMP отмечены флажками
4. Увеличьте или уменьшите Порты прослушивания на 1
5. Сохраните изменения и выйдите.

Это все, что у нас есть для этого поста, мы надеемся, что проблема с BitTorrent или uTorrent, которая не загружается или не подключается к Peers, решена. Дайте нам знать в комментариях, что сработало и есть ли у вас лучшее решение.

Справочное руководство для OpenVPN 2.4

Шифрование (и аутентификация) пакетов канала управления:

• обеспечивает большую конфиденциальность, скрывая сертификат, используемый для подключения TLS
• затрудняет идентификацию трафика OpenVPN как такового
• обеспечивает постквантовую защиту «для бедняков» от злоумышленников, которые никогда не узнают предварительный общий ключ (т.16 (65536) пакетов (для осторожности), и (повторное) согласование происходит каждую минуту для каждого пользователя (24/7), это ограничивает время жизни ключа tls-crypt до 8171 года, деленного на количество пользователей. Таким образом, установка с 1000 пользователями должна менять ключ не реже одного раза в восемь лет. (И установка с 8000 пользователей каждый год.)

  Если возникнут коллизии IV, это может привести к снижению безопасности —tls-crypt до того же уровня безопасности, что и при использовании —tls-auth . То есть канал управления по-прежнему выигрывает от дополнительной защиты от активных атак «человек посередине» и DoS-атак, но больше не может обеспечивать дополнительную конфиденциальность и постквантовую безопасность в дополнение к тому, что предлагает сам TLS.

  —askpass [файл] Получите пароль сертификата из консоли или из файла  до запуска демона.

  Для тех, кто особенно заботится о безопасности, можно защитить свой закрытый ключ паролем. Конечно, это означает, что каждый раз, когда запускается демон OpenVPN, вы должны быть там, чтобы ввести пароль. Параметр —askpass позволяет запускать OpenVPN из командной строки. Он запросит у вас пароль перед демонизацией. Чтобы защитить закрытый ключ паролем, следует опустить параметр -nodes при использовании инструмента командной строки openssl для управления сертификатами и закрытыми ключами.

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

  —auth-nocache Не кэшировать —askpass или —auth-user-pass  имя пользователя и пароли в виртуальной памяти.

  Если указано, эта директива заставит OpenVPN немедленно забыть введенные имя пользователя и пароль после их использования.В результате, когда OpenVPN требуется имя пользователя/пароль, он будет запрашивать ввод со стандартного ввода, который может быть несколько раз в течение сеанса OpenVPN.

  При использовании —auth-nocache в сочетании с файлом пользователя/пароля и —chroot или —daemon обязательно используйте абсолютный путь.

  Эта директива не влияет на —http-proxy имя пользователя/пароль. Он всегда кешируется.

  —auth-token token Этот параметр нельзя использовать напрямую в каких-либо файлах конфигурации, а скорее использовать этот параметр из сценария —client-connect или —plugin , который подключается к OPENVPN_PLUGIN_CLIENT_CONNECT. или вызовы OPENVPN_PLUGIN_CLIENT_CONNECT_V2.Эта опция дает возможность заменить пароль клиента токеном аутентификации в течение всего срока службы клиента OpenVPN.

  Всякий раз, когда соединение пересматривается и срабатывает скрипт —auth-user-pass-verify или —plugin , использующий хук OPENVPN_PLUGIN_AUTH_USER_PASS_VERIFY, он будет передавать этот токен в качестве пароля вместо пароля пользователя. при условии. Токен аутентификации можно сбросить только при полном переподключении, когда сервер может передать клиенту новые параметры.Введенный пользователем пароль никогда не сохраняется после установки маркера аутентификации. Если серверная часть OpenVPN отклоняет токен аутентификации, клиент получит AUTH_FAIL и отключится.

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

  Чтобы использовать эту функцию, скрипт —client-connect или —plugin должен указать

    push "токен аутентификации UNIQUE_TOKEN_VALUE"
    

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

  —tls-verify cmd Выполните команду cmd , чтобы проверить имя X509 ожидающего подключения TLS, которое в противном случае прошло все другие тесты сертификации (за исключением отзыва с помощью директивы —crl-verify ; тест отзыва происходит после теста —tls-verify ).

  cmd  должно вернуть 0, чтобы продолжить рукопожатие TLS, или 1, если произошла ошибка.

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

  При выполнении cmd два аргумента добавляются после любых аргументов, указанных в cmd , следующим образом:

  cmd certificate_depth тема

  Эти аргументы представляют собой, соответственно, текущую глубину сертификата и общее имя (cn) узла X509.

  Эта функция полезна, если одноранговый узел, которому вы хотите доверять, имеет сертификат, подписанный центром сертификации, который также подписал множество других сертификатов, когда вы не обязательно хотите доверять всем им, а скорее выбираете сертификат однорангового узла. ты примешь. Эта функция позволяет вам написать сценарий, который будет проверять имя X509 в сертификате и решать, следует ли его принимать. Простой сценарий Perl, который будет проверять поле общего имени в сертификате, см. в файле verify-cn в дистрибутиве OpenVPN.

  Дополнительные параметры, передаваемые в качестве переменных среды, см. в разделе «Переменные среды» ниже.

  —tls-export-cert directory Хранить сертификаты, которые клиенты используют при подключении к этому каталогу. Это будет сделано до вызова —tls-verify. Сертификаты будут использовать временное имя и будут удалены, когда сценарий tls-verify вернется. Имя файла, используемого для сертификата, доступно через переменную среды peer_cert. —x509-username-field [ext:]fieldname Поле в X.509 сертификат, подлежащий использованию в качестве имени пользователя (по умолчанию = CN). Как правило, этот параметр указывается с fieldname одним из следующих вариантов:

  —x509-username-field:  emailAddress
  —x509-username-field ext: subjectAltName

  В первом примере в качестве имени пользователя используется значение атрибута «emailAddress» в поле «Тема» сертификата. Во втором примере префикс ext: используется для обозначения того, что расширение X.509 fieldname  «subjectAltName» будет искать поле rfc822Name (электронная почта), которое будет использоваться в качестве имени пользователя.В случаях, когда в ext:fieldname содержится несколько адресов электронной почты, выбирается последнее вхождение.

  При использовании этого параметра параметр —verify-x509-name будет соответствовать выбранному имени поля вместо Общего имени.

  Поддерживаются только расширения subjectAltName и issuerAltName X.509.

  Обратите внимание:  У этого параметра есть функция, которая преобразует все строчные  имя поля  в прописные символы, например.г., оу -> оу. Имя поля в смешанном регистре или поле с префиксом ext: останется без изменений. Эта функция автоматического повышения регистра устарела и будет удалена в следующем выпуске.

  —verify-x509-name тип имени Принимать соединения, только если имя хоста X.509 равно имени .  Удаленный хост также должен пройти все остальные тесты проверки.

  Какое имя X.509 сравнивается с именем , зависит от настройки типа. введите  может быть «subject», чтобы соответствовать полному DN субъекта (по умолчанию), «name», чтобы соответствовать RDN субъекта, или «name-prefix», чтобы соответствовать префиксу RDN субъекта. Какое RDN проверяется как имя, зависит от параметра —x509-username-field . Но по умолчанию используется общее имя (CN), например. сертификат с DN субъекта «C=KG, ST=NA, L=Bishkek, CN=Server-1» будет соответствовать:

  —verify-x509-name ‘C=KG, ST=NA, L=Bishkek, CN=Server-1’  и  —verify-x509-name Имя сервера-1  или вы можете использовать — verify-x509-name Server-name-prefix  , если вы хотите, чтобы клиент принимал подключения только к «Серверу-1», «Серверу-2» и т. д.

  —verify-x509-name  – полезная замена опции  —tls-verify для проверки удаленного хоста, поскольку —verify-x509-name  работает в среде  —chroot без любые зависимости.

  Использование префикса имени является полезной альтернативой управлению CRL (списком отозванных сертификатов) на клиенте, поскольку позволяет клиенту отклонять все сертификаты, кроме тех, которые связаны с назначенными серверами.

  ПРИМЕЧАНИЕ.  Проверяйте префикс имени только в том случае, если вы используете OpenVPN с собственным сертификатом ЦС, который находится под вашим контролем.Никогда не используйте этот параметр с типом «префикс имени», если ваши клиентские сертификаты подписаны третьей стороной, например коммерческим веб-центром сертификации.

  —x509-track attribute Сохранить значение атрибута однорангового узла X509   в среде для использования подключаемыми модулями и интерфейсом управления. Добавьте «+» к   атрибуту  , чтобы сохранить значения из полной цепочки сертификатов. Значения будут закодированы как X509_<глубина>_<атрибут>=<значение>. Можно задать несколько параметров —x509-track для отслеживания нескольких атрибутов. —ns-cert-type client|server УСТАРЕЛО  Эта опция будет удалена в OpenVPN 2.5. Вместо этого используйте более современный эквивалент —remote-cert-tls . Эта опция будет удалена в OpenVPN 2.5.

  Требовать, чтобы одноранговый сертификат был подписан с явным nsCertType обозначением «клиент» или «сервер».

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

  См. скрипт easy-rsa/build-key-server для примера создания сертификата с полем  nsCertType , для которого установлено значение «сервер».

  Если в поле nsCertType сертификата сервера указано значение «сервер», клиенты могут проверить это с помощью —ns-cert-type server.

  Это важная мера безопасности для защиты от атаки посредника, когда авторизованный клиент пытается подключиться к другому клиенту, выдавая себя за сервер. Атаку легко предотвратить, если клиенты проверят сертификат сервера, используя любой из —ns-cert-type, —verify-x509-name, или —tls-verify.

  —remote-cert-ku [v…] Требовать, чтобы одноранговый сертификат был подписан с явным использованием ключа .

  При наличии в сертификате значение keyUsage проверяется библиотекой TLS во время рукопожатия TLS. Указание этого параметра без аргументов требует наличия этого расширения (поэтому библиотека TLS проверит его).

  Если список v… также предоставлен, поле keyUsage должно иметь по крайней мере  те же биты, установленные как биты в одно из значений, предоставленных в списке v…

  Значения использования ключа в списке должны быть закодированы в шестнадцатеричном формате, например. «—remote-cert-ku a0»

  —remote-cert-eku oid Требовать, чтобы одноранговый сертификат был подписан с явным использованием расширенного ключа .

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

  Использование расширенного ключа должно быть закодировано в нотации oid или в символьном представлении OpenSSL.

  —remote-cert-tls client|server Требовать, чтобы одноранговый сертификат был подписан с явным использованием ключа и расширенным использованием ключа на основе правил RFC3280 TLS.

  Это полезная опция безопасности для клиентов, гарантирующая, что хост, к которому они подключаются, является назначенным сервером. Или наоборот; для сервера, чтобы убедиться, что только хосты с клиентским сертификатом могут подключаться.

  Параметр —remote-cert-tls client эквивалентен —remote-cert-ku —remote-cert-eku «Аутентификация веб-клиента TLS»

  Параметр —remote-cert-tls server эквивалентен —remote-cert-ku —remote-cert-eku «Аутентификация веб-сервера TLS»

  Это важная мера безопасности для защиты от атаки посредника, когда авторизованный клиент пытается подключиться к другому клиенту, выдавая себя за сервер.Атаку легко предотвратить, если клиенты проверят сертификат сервера с помощью одного из —remote-cert-tls, —verify-x509-name, или —tls-verify.

  —crl-verify crl [‘dir’] Проверить сертификат узла по файлу crl  в формате PEM.

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

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

  Единственным случаем, когда потребуется перестроить всю PKI с нуля, может быть компрометация самого ключа корневого сертификата.

  Если указан необязательный флаг dir , включите другой режим, где crl  – это каталог, содержащий файлы с отозванными серийными номерами (файлы могут быть пустыми, их содержимое никогда не читается).Если клиент запрашивает соединение, где серийный номер сертификата клиента (десятичная строка) является именем файла, присутствующего в каталоге, он будет отклонен.

  Примечание. Поскольку файл crl (или каталог) считывается каждый раз при подключении однорангового узла, если вы отказываетесь от привилегий root с помощью  —user,  , убедитесь, что у этого пользователя достаточно прав для чтения файла.

   

  Информация о библиотеке SSL:

  —show-шифры

  (автономный) Показать все алгоритмы шифрования для использования с параметром —cipher .

  —show-дайджесты

  (автономный) Показать все алгоритмы дайджеста сообщений для использования с параметром —auth .

  —show-TLS

  (автономный) Показать все шифры TLS, поддерживаемые криптобиблиотекой. OpenVPN использует TLS для защиты канала управления, по которому происходит обмен ключами, которые используются для защиты фактического трафика VPN. Шифры TLS будут отсортированы от самого высокого предпочтения (наиболее безопасного) к самому низкому. Имейте в виду, что то, может ли набор шифров в этом списке действительно работать, зависит от конкретной настройки обоих одноранговых узлов (т.г. оба одноранговых узла должны поддерживать шифр, и набор шифров ECDSA не будет работать, если вы используете сертификат RSA и т. д.).

  —двигатели шоу

  (автономный) Показать доступные в настоящее время аппаратные механизмы криптоускорения, поддерживаемые библиотекой OpenSSL.

  —показать кривые

  (автономный) Показать все доступные эллиптические кривые для использования с параметром —ecdh-curve .

  Создать случайный ключ:

  Используется только для режима шифрования со статическим ключом, отличного от TLS.

  —genkey

  (автономный) Создание случайного ключа для использования в качестве общего секрета для использования с параметром —secret . Этот файл должен быть передан партнеру по уже существующему безопасному каналу, например scp

  .

  —секретный файл

  Запись ключа в файл .

  Режим конфигурации постоянного туннеля TUN/TAP:

  Доступно в Linux 2.4.7+. Эти параметры включают автономный режим OpenVPN, который можно использовать для создания и удаления постоянных туннелей.

  —мктун

  (автономный) Создайте постоянный туннель на платформах, которые их поддерживают, таких как Linux. Обычно туннели TUN/TAP существуют только в течение периода времени, когда они открыты приложением. В этом варианте используется возможность драйвера TUN/TAP создавать постоянные туннели, которые существуют через несколько экземпляров OpenVPN и отключаются только при их удалении или перезагрузке машины. Одно из преимуществ постоянных туннелей заключается в том, что они устраняют необходимость в отдельных —up  и —down  скрипты для запуска соответствующих команд ifconfig и route .Эти команды можно поместить в тот же сценарий оболочки, который запускает или завершает сеанс OpenVPN.

  Еще одним преимуществом является то, что открытые соединения через туннель на основе TUN/TAP не будут сброшены при перезапуске однорангового узла OpenVPN. Это может быть полезно для обеспечения бесперебойного подключения через туннель в случае сброса DHCP общедоступного IP-адреса узла (см. параметр —ipchange выше).

  Одним из недостатков постоянных туннелей является сложность автоматической настройки значения MTU (см. —link-mtu и —tun-mtu выше).

  На некоторых платформах, таких как Windows, туннели TAP-Win32 по умолчанию являются постоянными.

  —rmtun

  (автономный) Удаление постоянного туннеля.

  —dev tunX | tapX

  Устройство TUN/TAP

  —user пользователь

  Необязательный пользователь, который будет владельцем этого туннеля.

  —группа

  Необязательная группа, которая будет владельцем этого туннеля.

  Параметры для Windows:

  —win-sys путь

  Укажите путь к системному каталогу Windows, который будет использоваться при поиске системных исполняемых файлов, например маршрут .exe и netsh.exe.  По умолчанию, если эта директива не указана, OpenVPN будет использовать переменную среды SystemRoot. Этот параметр изменил поведение в OpenVPN 2.3. Ранее вам нужно было определить —win-sys env , чтобы использовать переменную среды SystemRoot, иначе по умолчанию использовалась C:\WINDOWS. Ключевое слово env больше не нужно использовать, и оно будет просто проигнорировано. При обнаружении этого в файле конфигурации регистрируется предупреждение.

  —метод ip-win32

  При использовании —ifconfig в Windows задайте IP-адрес и сетевую маску адаптера TAP-Win32 с помощью метода .  Не используйте этот параметр, если вы также не используете —ifconfig. manual —  Не устанавливайте IP-адрес или сетевую маску автоматически. Вместо этого выведите на консоль сообщение, предлагающее пользователю настроить адаптер вручную и указывающее IP/сетевую маску, которую OpenVPN ожидает установить для адаптера.

  dynamic [смещение] [время аренды] —  Автоматически установить IP-адрес и сетевую маску, отвечая на сообщения DHCP-запроса, созданные ядром. Этот режим, вероятно, является самым «чистым» решением для настройки свойств TCP/IP, поскольку он использует хорошо известный протокол DHCP.Однако есть два предварительных условия для использования этого режима: (1) свойства TCP/IP для адаптера TAP-Win32 должны быть установлены на «Получить IP-адрес автоматически» и (2) OpenVPN должен запросить IP-адрес в подсеть для использования в качестве адреса виртуального DHCP-сервера. По умолчанию в режиме —dev tap OpenVPN использует обычно неиспользуемый первый адрес в подсети. Например, если ваша подсеть 192.168.4.0, маска сети 255.255.255.0, то OpenVPN возьмет IP-адрес 192.168.4.0 для использования в качестве адреса виртуального DHCP-сервера.В режиме  —dev tun OpenVPN заставит DHCP-сервер маскироваться, как если бы он исходил из удаленной конечной точки. Необязательный параметр смещения представляет собой целое число от > -256 до < 256, по умолчанию равное -1. Если смещение положительное, DHCP-сервер будет маскироваться под IP-адрес по сетевому адресу + смещение. Если смещение отрицательное, DHCP-сервер будет маскироваться под IP-адрес с широковещательным адресом + смещение. Команду Windows ipconfig /all можно использовать, чтобы показать, что Windows считает адресом DHCP-сервера.OpenVPN «заявит» этот адрес, поэтому обязательно используйте свободный адрес. При этом разные экземпляры OpenVPN, включая разные концы одного и того же соединения, могут использовать один и тот же адрес виртуального DHCP-сервера. Параметр Lease-Time определяет время аренды назначения DHCP для адаптера TAP-Win32 и указывается в секундах. Обычно предпочтение отдается очень длительному времени аренды, поскольку оно предотвращает потерю маршрутов с участием адаптера TAP-Win32, когда система переходит в спящий режим.Срок аренды по умолчанию составляет один год.

  netsh —  Автоматически установить IP-адрес и сетевую маску с помощью команды «netsh» из командной строки Windows. Этот метод работает корректно в Windows XP, но не в Windows 2000.

  ipapi —  Автоматически установить IP-адрес и сетевую маску с помощью Windows IP Helper API. Этот подход не имеет идеальной семантики, хотя тестирование показало, что на практике он работает нормально. Если вы используете этот параметр, лучше всего оставить свойства TCP/IP для адаптера TAP-Win32 в состоянии по умолчанию, т.е.е. «Получить IP-адрес автоматически».

  адаптивный —  (по умолчанию) Сначала попробуйте динамический метод  и переключитесь на netsh  , если согласование DHCP с адаптером TAP-Win32 не увенчается успехом в течение 20 секунд. Известно, что такие сбои происходят, когда определенные сторонние пакеты брандмауэра, установленные на клиентском компьютере, блокируют согласование DHCP, используемое адаптером TAP-Win32. Обратите внимание, что в случае аварийного переключения netsh свойства TCP/IP адаптера TAP-Win32 будут сброшены с DHCP на статические, и это приведет к тому, что будущие запуски OpenVPN с использованием адаптивного режима будут использовать netsh немедленно, а не пытаться динамический  первый.Чтобы «отвязать» адаптивный режим от использования netsh, запустите OpenVPN хотя бы один раз, используя динамический режим , чтобы восстановить свойства TCP/IP адаптера TAP-Win32 до конфигурации DHCP.

  —метод-маршрута м

  Какой метод m использовать для добавления маршрутов в Windows? адаптивный  (по умолчанию) – сначала попробуйте вспомогательный API IP. Если это не поможет, вернитесь к команде оболочки route.exe.
  ipapi  – Используйте вспомогательный API IP.
  exe ​​ — вызовите команду оболочки route.exe.

  —dhcp-опция тип [параметр]

  Установить расширенные свойства TAP-Win32 TCP/IP, необходимо использовать с —ip-win32 dynamic или —ip-win32 Adaptive.  Этот параметр можно использовать для установки дополнительных свойств TCP/IP адаптера TAP-Win32, и он особенно полезен для настройки клиента OpenVPN для доступа к серверу Samba через VPN. Имя ДОМЕНА —  Задайте DNS-суффикс для конкретного подключения.

  DNS-адрес —  Установите IPv4- или IPv6-адрес основного сервера доменных имен. Повторите этот параметр, чтобы задать адреса вторичных DNS-серверов.

  Примечание. DNS-серверы IPv6 в настоящее время настроены с использованием netsh (существующий код DHCP может использовать только IPv4 DHCP, а этот протокол разрешает только IPv4-адреса в любом месте). Опция будет помещена в среду, поэтому при необходимости с ней может работать сценарий —up .

  Адрес WINS —  Установите адрес основного сервера WINS (NetBIOS через сервер имен TCP/IP).Повторите этот параметр, чтобы задать адреса вторичного WINS-сервера.

  Адрес NBDD —  Установить адрес основного сервера NBDD (NetBIOS через сервер распространения дейтаграмм TCP/IP). Повторите этот параметр, чтобы задать адреса вторичного сервера NBDD.

  Адрес NTP —  Установите адрес основного сервера NTP (протокол сетевого времени). Повторите этот параметр, чтобы задать адреса вторичных серверов NTP.

  Тип NBT —  Установить тип узла NetBIOS через TCP/IP. Возможные варианты: 1  = b-узел (широковещательные рассылки), 2  = p-узел (двухточечные запросы имен к WINS-серверу), 4  = m-узел (широковещательные рассылки, а затем запросы к серверу имен), и 8  = h-узел (сервер имен запросов, затем широковещательная рассылка).

  Идентификатор области действия NBS —  Установить область действия NetBIOS через TCP/IP. Идентификатор области действия NetBIOS предоставляет расширенную службу именования для модуля NetBIOS через TCP/IP (известного как NBT). Основная цель идентификатора области действия NetBIOS состоит в том, чтобы изолировать трафик NetBIOS в одной сети только для тех узлов с таким же идентификатором области действия NetBIOS. Идентификатор области NetBIOS — это строка символов, которая добавляется к имени NetBIOS. Идентификатор области NetBIOS на двух хостах должен совпадать, иначе два хоста не смогут обмениваться данными.Идентификатор области NetBIOS также позволяет компьютерам использовать одно и то же имя компьютера, поскольку они имеют разные идентификаторы области. Scope ID становится частью имени NetBIOS, что делает имя уникальным. (Это описание областей NetBIOS предоставлено [email protected])

  DISABLE-NBT —  Отключить Netbios-over-TCP/IP.

  Обратите внимание: если —dhcp-option  передается через —push клиенту, отличному от Windows, параметр будет сохранен в среде клиента до вызова сценария up под именем «foreign_option_{n} «.

  —tap-sleep n

  Заставляет OpenVPN переходить в спящий режим на n секунд сразу после того, как состояние адаптера TAP-Win32 установлено на «подключено». Этот параметр предназначен для устранения неполадок с —ifconfig и —ip-win32 . параметров и используется для того, чтобы дать адаптеру TAP-Win32 время для включения до того, как к нему будут применены операции Windows IP Helper API.

  —show-net-up

  Выводить представление OpenVPN о системной таблице маршрутизации и списке сетевых адаптеров в системный журнал или файл журнала после запуска адаптера TUN/TAP и добавления любых маршрутов.

  —block-outside-dns

  Заблокируйте DNS-серверы на других сетевых адаптерах, чтобы предотвратить утечку DNS. Этот параметр запрещает любому приложению доступ к TCP- или UDP-порту 53, кроме одного, находящегося внутри туннеля. Он использует платформу фильтрации Windows (WFP) и работает в Windows Vista или более поздних версиях. Этот параметр считается неизвестным на платформах, отличных от Windows, и не поддерживается в Windows XP, что приводит к фатальной ошибке. Вы можете использовать —setenv opt или —ignore-unknown-option (не подходит для Windows XP), чтобы игнорировать указанную ошибку.Обратите внимание, что передача неизвестных параметров с сервера не приводит к фатальным ошибкам.

  —dhcp-обновить

  Попросите Windows продлить аренду адаптера TAP при запуске. Этот параметр обычно не нужен, так как Windows автоматически инициирует повторное согласование DHCP на TAP-адаптере, когда он появляется, однако, если вы установите для свойства Media Status адаптера TAP-Win32 значение «Всегда подключен», вам может понадобиться этот флаг.

  —dhcp-выпуск

  Попросите Windows освободить аренду TAP-адаптера при завершении работы.Эта опция сейчас не действует, так как она включена по умолчанию, начиная с OpenVPN 2.4.1.

  —регистр-DNS

  Запускать ipconfig /flushdns и ipconfig /registerdns при инициации подключения. Известно, что это заставляет Windows распознавать проталкиваемые DNS-серверы.

  —пауза-выход

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

  —событие выхода службы [0|1]

  Следует использовать, когда OpenVPN автоматически запускается другой программой в таком контексте, что взаимодействие с пользователем через дисплей или клавиатуру невозможно. Как правило, конечным пользователям не нужно явно использовать эту опцию, поскольку она автоматически добавляется оболочкой службы OpenVPN, когда данная конфигурация OpenVPN запускается как служба. exit-event — это имя объекта глобального события Windows, и OpenVPN будет постоянно отслеживать состояние этого объекта события и выходить, когда он получает сигнал.

  Второй параметр указывает исходное состояние exit-event и обычно по умолчанию равен 0.

  Несколько процессов OpenVPN могут выполняться одновременно с одним и тем же параметром exit-event . В любом случае управляющий процесс может сигнализировать exit-event, вызывая завершение всех таких процессов OpenVPN.

  При выполнении процесса OpenVPN с использованием директивы —service OpenVPN, вероятно, не будет иметь окна консоли для вывода сообщений о состоянии/ошибках, поэтому полезно использовать —log или —log-append для записать эти сообщения в файл.

  —show-адаптеры

  (автономный) Показать доступные адаптеры TAP-Win32, которые можно выбрать с помощью параметра —dev-node . В системах, отличных от Windows, аналогичную функциональность обеспечивает команда ifconfig .

  —allow-nonadmin [TAP-адаптер]

  (автономный) Установите  TAP-адаптер , чтобы разрешить доступ из учетных записей без прав администратора. Если TAP-адаптер не указан, все TAP-адаптеры в системе будут настроены на разрешение доступа без прав администратора.Параметр доступа без прав администратора будет сохраняться только в течение времени, пока объект устройства TAP-Win32 и драйвер остаются загруженными, и его необходимо будет повторно включить после перезагрузки или если драйвер выгружается и перезагружается. Эта директива может использоваться только администратором.

  —show-valid-subnets

  (автономный) Показать допустимые подсети для эмуляции —dev tun . Поскольку драйвер TAP-Win32 экспортирует интерфейс Ethernet в Windows, а устройства TUN по своей природе являются двухточечными, для драйвера TAP-Win32 необходимо наложить определенные ограничения на выбор адреса конечной точки TUN.А именно, конечные точки «точка-точка», используемые в эмуляции устройства TUN, должны быть двумя средними адресами подсети /30 (сетевая маска 255.255.255.252).

  —показ-нет

  (автономный) Показать представление OpenVPN системной таблицы маршрутизации и списка сетевых адаптеров.

  PKCS#11 Автономные опции:

  —show-pkcs11-ids [поставщик] [cert_private]

  (автономный) Показать список объектов токенов PKCS#11. Укажите cert_private как 1, если сертификаты хранятся как частные объекты.Если в системе присутствует p11-kit, аргумент провайдера является необязательным; если опущено, будет запрошен модуль по умолчанию p11-kit-proxy.so .
  —verb Параметр можно использовать ДО этого параметра для получения отладочной информации.

  Параметры автономной отладки:

  —show-шлюз [v6target]

  (автономный) Показать текущий шлюз IPv4 и IPv6 по умолчанию и интерфейс к шлюзу (если соответствующий протокол включен).Если в качестве аргумента передается адрес IPv6, сообщается маршрут IPv6 для этого хоста.

  Связанные параметры IPv6

  Существуют следующие параметры для поддержки туннелирования IPv6 в одноранговом и клиент-серверном режимах. Все параметры смоделированы по аналогии с IPv4, поэтому более подробные пояснения, приведенные там, применимы и здесь (за исключением —topology , который не влияет на IPv6).

  —ifconfig-ipv6 ipv6addr/bits ipv6remote

  настроить IPv6-адрес ipv6addr/bits на устройстве «tun».Второй параметр используется в качестве цели маршрута для —route-ipv6 , если шлюз не указан.

  —route-ipv6 ipv6addr/bits [шлюз] [метрика]

  настроить маршрутизацию IPv6 в системе для отправки указанной сети IPv6 в «tun» OpenVPN. Параметр шлюза используется только для маршрутов IPv6 через устройства «tap». Если он отсутствует, используется поле «ipv6remote» из  —ifconfig-ipv6 .

  —сервер-ipv6 ipv6addr/бит

  удобная функция для одновременного включения нескольких параметров, связанных с IPv6, а именно —ifconfig-ipv6, —ifconfig-ipv6-pool и —push tun-ipv6  Допускается, только если «—mode server » или «—server».Вставка директивы —tun-ipv6 выполняется для старых клиентов, которые требуют явного указания «—tun-ipv6» в своей конфигурации.

  —ifconfig-ipv6-пул ipv6addr/бит

  Укажите пул адресов IPv6 для динамического назначения клиентам. Пул начинается с ipv6addr и соответствует смещению, определенному от начала пула IPv4.

  —ifconfig-ipv6-push ipv6addr/bits ipv6remote

  для настройки статического интерфейса IPv6 ccd/на клиента, см. —client-config-dir и —ifconfig-push для получения дополнительной информации.

  —iroute-ipv6 ipv6addr/бит

  для конфигурации статического маршрута IPv6 ccd/на клиента см. —iroute  для получения дополнительной информации о том, как настроить и использовать это, а также о том, как —iroute  и —route взаимодействуют.

  OpenVPN экспортирует ряд переменных среды для использования пользовательскими сценариями.

  Порядок выполнения скрипта

  —до

  Выполняется после привязки сокета TCP/UDP и открытия TUN/TAP.

  —tls-проверить

  Выполняется, когда у нас есть еще ненадежный удаленный узел.

  —ipchange

  Выполняется после аутентификации подключения или изменения удаленного IP-адреса.

  —клиент-подключение

  Выполняется в режиме —mode server сразу после аутентификации клиента.

  —маршрут вверх

  Выполняется после аутентификации подключения, либо сразу после, либо через некоторое количество секунд после того, как определено параметром —route-delay .

  —route-pre-down

  Выполняется непосредственно перед удалением маршрутов.

  —клиент-отключение

  Выполняется в режиме —mode server при завершении работы экземпляра клиента.

  —вниз

  Выполняется после закрытия TCP/UDP и TUN/TAP.

  —адрес обучения

  Выполняется в режиме —mode server всякий раз, когда IPv4-адрес/маршрут или MAC-адрес добавляются во внутреннюю таблицу маршрутизации OpenVPN.

  —auth-user-pass-verify

  Выполняется в режиме —mode server при новых клиентских подключениях, когда клиент еще не является доверенным.

  Типы строк и переназначение

  В некоторых случаях OpenVPN будет выполнять переназначение символов в строках. По сути, любые символы за пределами набора разрешенных символов для каждого типа строки будут преобразованы в символ подчеркивания (‘_’).

  В:  Зачем необходимо переназначение строк?

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

  В: Можно ли отключить переназначение строк?

  A:  Да, с помощью параметра —no-name-remapping , однако его следует рассматривать как расширенный вариант.

  Вот краткое изложение текущих типов строк OpenVPN и разрешенного класса символов для каждой строки:

  X509 Имена:  Буквенно-цифровой, подчеркивание (‘_’), тире (‘-‘), точка (‘.’), at (‘@’), двоеточие (‘:’), косая черта (‘/’), и равны (‘=’). Буквенно-цифровой определяется как символ, который заставит функцию isalnum() библиотеки C вернуть значение true.

  Распространенные имена:  Буквенно-цифровой, подчеркивание (‘_’), тире (‘-‘), точка (‘.’) и at (‘@’).

  —auth-user-pass имя пользователя:  То же, что и обычное имя, за одним исключением: начиная с OpenVPN 2.0.1, имя пользователя передается плагину OPENVPN_PLUGIN_AUTH_USER_PASS_VERIFY в необработанном виде, без переназначения строк.

  —auth-user-pass password:  Любой «печатный» символ, кроме CR или LF. Printable определяется как символ, который заставит функцию isprint() библиотеки C вернуть значение true.

  —client-config-dir имя файла, полученное из общего имени или имени пользователя:  Буквенно-цифровой, подчеркивание (‘_’), тире (‘-‘) и точка (‘.’), кроме «.» или «..» как отдельные строки. Начиная с v2.0.1-rc6, также был добавлен символ at (‘@’) для совместимости с классом символов общего имени.

  Имена переменных среды: Буквенно-цифровые символы или символы подчеркивания («_»).

  Значения переменных среды:  Любой печатный символ.

  Во всех случаях символы в строке, которые не являются членами допустимого класса символов для этого типа строки, будут переназначены на символ подчеркивания (‘_’).

  Переменные среды

  После установки переменная сохраняется неопределенно долго, пока она не будет сброшена новым значением или перезапущена,

  Начиная с OpenVPN 2.0-beta12, в режиме сервера переменные среды, установленные OpenVPN, имеют область действия в соответствии с объектами клиента, с которыми они связаны, поэтому не должно быть никаких проблем со сценариями, имеющими доступ к устаревшим, ранее установленным переменным, которые ссылаются на разные клиентские экземпляры.

  байт_получено

  Общее количество байтов, полученных от клиента во время сеанса VPN.Установите перед выполнением сценария —client-disconnect .

  байт_отправлено

  Общее количество байтов, отправленных клиенту во время сеанса VPN. Установите перед выполнением сценария —client-disconnect .

  общее_имя

  Общее имя X509 аутентифицированного клиента. Задается перед выполнением сценариев —client-connect, —client-disconnect, и —auth-user-pass-verify .

  конфигурация

  Имя первого —config файла.Устанавливается при запуске программы и сбрасывается при SIGHUP.

  демон

  Установите значение «1», если указана директива —daemon , или «0» в противном случае. Устанавливается при запуске программы и сбрасывается при SIGHUP.

  daemon_log_redirect

  Установите значение «1», если указаны директивы —log или —log-append , или «0» в противном случае. Устанавливается при запуске программы и сбрасывается при SIGHUP.

  разработчик

  Фактическое имя устройства TUN/TAP, включая номер модуля, если он существует.Установите перед выполнением скрипта —up или —down .

  dev_idx

  В Windows индекс устройства адаптера TUN/TAP (для использования в вызовах netsh.exe, которые иногда неправильно работают с именами интерфейсов). Установите перед выполнением скрипта —up или —down .

  Foreign_option_{n}

  Опция, переданная через —push клиенту, который ее изначально не поддерживает, например —dhcp-option в системе, отличной от Windows, будет записана в эту последовательность переменных среды до —up выполнение скрипта.

  ifconfig_broadcast

  Широковещательный адрес для виртуального сегмента Ethernet, полученный из параметра —ifconfig при использовании —dev tap . Установите до того, как OpenVPN вызовет команды ifconfig или netsh (версия ifconfig для Windows), что обычно происходит перед выполнением скрипта —up .

  ifconfig_ipv6_local

  IPv6-адрес локальной конечной точки VPN, указанный в параметре —ifconfig-ipv6 (первый параметр).Установите до того, как OpenVPN вызовет команды ifconfig или netsh (версия ifconfig для Windows), что обычно происходит перед выполнением скрипта —up .

  ifconfig_ipv6_netbits

  Длина префикса сети IPv6 на интерфейсе VPN. Получено из параметра /nnn адреса IPv6 в опции —ifconfig-ipv6 (первый параметр). Установите до того, как OpenVPN вызовет команды ifconfig или netsh (версия ifconfig для Windows), что обычно происходит перед выполнением скрипта —up .

  ifconfig_ipv6_remote

  IPv6-адрес удаленной конечной точки VPN, указанный в параметре —ifconfig-ipv6 (второй параметр). Установите до того, как OpenVPN вызовет команды ifconfig или netsh (версия ifconfig для Windows), что обычно происходит до выполнения скрипта —up .

  ifconfig_local

  IP-адрес локальной конечной точки VPN, указанный в параметре —ifconfig (первый параметр).Установите до того, как OpenVPN вызовет команды ifconfig или netsh (версия ifconfig для Windows), что обычно происходит перед выполнением скрипта —up .

  ifconfig_remote

  IP-адрес удаленной конечной точки VPN, указанный в опции —ifconfig (второй параметр) при использовании —dev tun . Установите до того, как OpenVPN вызовет команды ifconfig или netsh (версия ifconfig для Windows), что обычно происходит перед выполнением скрипта —up .

  ifconfig_netmask

  Маска подсети виртуального сегмента Ethernet, указанная вторым параметром для —ifconfig , когда используется —dev tap . Установите до того, как OpenVPN вызовет команды ifconfig или netsh (версия ifconfig для Windows), что обычно происходит перед выполнением скрипта —up .

  ifconfig_pool_local_ip

  Локальный виртуальный IP-адрес для туннеля TUN/TAP, взятый из директивы —ifconfig-push , если она указана, или из пула ifconfig (управляемого директивой файла конфигурации —ifconfig-pool ).Устанавливается только для —dev tun туннелей. Этот параметр задается на сервере перед выполнением сценариев —client-connect и —client-disconnect .

  ifconfig_pool_netmask

  Виртуальная IP-маска сети для туннеля TUN/TAP, взятая из директивы —ifconfig-push , если она указана, или из пула ifconfig (управляется директивой файла конфигурации —ifconfig-pool ). Установить только для —dev tap туннелей.Этот параметр задается на сервере перед выполнением сценариев —client-connect и —client-disconnect .

  ifconfig_pool_remote_ip

  Удаленный виртуальный IP-адрес для туннеля TUN/TAP, полученный из директивы —ifconfig-push , если она указана, или из пула ifconfig (управляемого директивой файла конфигурации —ifconfig-pool ). Этот параметр задается на сервере перед выполнением сценариев —client-connect и —client-disconnect .

  link_mtu

  Максимальный размер пакета (не включая IP-заголовок) данных туннеля в транспортном режиме туннеля UDP. Установите перед выполнением скрипта —up или —down .

  местный

  Параметр —local . Устанавливается при запуске программы и сбрасывается при SIGHUP.

  локальный_порт

  Номер или имя локального порта, указанное с помощью —port или —lport.  Устанавливается при запуске программы и сбрасывается при SIGHUP.

  пароль

  Пароль, предоставленный подключающимся клиентом. Устанавливается перед выполнением сценария —auth-user-pass-verify только при указании модификатора via-env и удаляется из среды после возврата сценария.

  прототип

  Параметр —proto . Устанавливается при запуске программы и сбрасывается при SIGHUP.

  remote_{n}

  Параметр —remote .Устанавливается при запуске программы и сбрасывается при SIGHUP.

  удаленный_порт_{n}

  Номер удаленного порта, указанный с помощью —port или —rport.  Устанавливается при запуске программы и сбрасывается при SIGHUP.

  route_net_gateway

  Ранее существовавший шлюз IP по умолчанию в таблице маршрутизации системы. Устанавливается перед выполнением скрипта —up .

  route_vpn_gateway

  Шлюз по умолчанию, используемый параметрами —route , как указано либо в параметре —route-gateway , либо во втором параметре —ifconfig , когда указан —dev tun .Устанавливается перед выполнением скрипта —up .

  route_{parm}_{n}

  Набор переменных, которые определяют каждый добавляемый маршрут и устанавливаются перед выполнением —up  скрипта. parm  будет иметь значение «сеть», «маска сети», «шлюз» или «метрика».

  n — номер маршрута OpenVPN, начиная с 1.

  Если сеть или шлюз имеют разрешимые DNS-имена, будут записаны их преобразования IP-адресов, а не их имена, указанные в командной строке или файле конфигурации.

  route_ipv6_{parm}_{n}

  Набор переменных, которые определяют каждый добавляемый маршрут IPv6 и устанавливаются перед выполнением сценария —up . parm  будет одним из слов «сеть» или «шлюз» («сетевая маска» содержится как «/nnn» в route_ipv6_network_{n}, в отличие от IPv4, где она передается в отдельной переменной среды).

  n — номер маршрута OpenVPN, начиная с 1.

  Если сеть или шлюз имеют разрешимые DNS-имена, будут записаны их преобразования IP-адресов, а не их имена, указанные в командной строке или файле конфигурации.

  одноранговый_сертификат

  Имя временного файла, содержащего сертификат клиента при подключении. Полезно в сочетании с —tls-verify

  скрипт_контекст

  Установите «инициализацию» или «перезапуск» перед выполнением сценария вверх/вниз. Для получения дополнительной информации см. документацию для —up.

  тип_скрипта

  Перед выполнением любого сценария в этой переменной устанавливается тип выполняемого сценария. Это может быть одно из следующих значений: up, down, ipchange, route-up, tls-verify, auth-user-pass-verify,   client-connect, client-disconnect, или Learn-address.  Устанавливается перед выполнением любого скрипта.

  сигнал

  Причина выхода или перезагрузки. Может быть одним из sigusr1, sighup, sigterm, sigint, inactive (управляется опцией —inactive ), ping-exit (управляется опцией —ping-exit ), ping-restart  управляется опцией —ping-restart ), connection-reset (запускается при сбросе TCP-соединения), ошибка, или unknown (неизвестный сигнал).Эта переменная устанавливается непосредственно перед выполнением скрипта down.

  time_ascii

  Отметка времени подключения клиента, отформатированная как удобочитаемая строка времени. Установите перед выполнением сценария —client-connect .

  время_длительность

  Продолжительность (в секундах) сеанса клиента, который сейчас отключается. Установите перед выполнением сценария —client-disconnect .

  time_unix

  Отметка времени подключения клиента, отформатированная как целочисленное значение даты/времени в формате unix.Установите перед выполнением сценария —client-connect .

  tls_digest_{n} / tls_digest_sha256_{n}

  Содержит отпечаток сертификата SHA1 / SHA256, где n — уровень проверки. Устанавливается только для соединений TLS. Установите перед выполнением сценария —tls-verify .

  tls_id_{n}

  Серия полей сертификата от удаленного узла, где n  – уровень проверки. Устанавливается только для соединений TLS.Установите перед выполнением сценария —tls-verify .

  tls_serial_{n}

  Серийный номер сертификата от удаленного узла, где n — уровень проверки. Устанавливается только для соединений TLS. Установите перед выполнением сценария —tls-verify . Это в виде десятичной строки, такой как «933971680», которая подходит для выполнения последовательных запросов OCSP (с OpenSSL не добавляйте «0x» к строке). Если что-то пойдет не так при чтении значения из сертификата, будет пустой строкой, поэтому ваш код должен это проверить.См. пример сценария contrib/OCSP_check/OCSP_check.sh.

  tls_serial_hex_{n}

  Аналогично tls_serial_{n} , но в шестнадцатеричном формате (например, «12:34:56:78:9A»).

  тун_мту

  MTU устройства TUN/TAP. Установите перед выполнением скрипта —up или —down .

  trust_ip (или trust_ip6)

  Фактический IP-адрес подключающегося клиента или узла, который прошел проверку подлинности.Задается перед выполнением сценариев —ipchange, —client-connect, и —client-disconnect . Если используются конечные точки ipv6 (udp6, tcp6), вместо них будет установлено trust_ip6 .

  доверенный_порт

  Фактический номер порта подключающегося клиента или однорангового узла, который прошел аутентификацию. Задается перед выполнением сценариев —ipchange, —client-connect, и —client-disconnect .

  untrusted_ip (или untrusted_ip6)

  Фактический IP-адрес подключающегося клиента или однорангового узла, который еще не прошел аутентификацию.Иногда используется для nmap подключающегося хоста в сценарии —tls-verify , чтобы убедиться, что он правильно защищен брандмауэром. Задается перед выполнением сценариев —tls-verify и —auth-user-pass-verify . При использовании конечных точек ipv6 (udp6, tcp6) вместо этого будет установлено untrusted_ip6 .

  недоверенный_порт

  Фактический номер порта подключающегося клиента или однорангового узла, который еще не прошел аутентификацию. Задается перед выполнением сценариев —tls-verify и —auth-user-pass-verify .

  имя пользователя

  Имя пользователя, предоставленное подключающимся клиентом. Устанавливается перед выполнением скрипта —auth-user-pass-verify только в том случае, если указан модификатор via-env .

  X509_{n}_{subject_field}

  Поле темы X509 из сертификата удаленного узла, где n — уровень проверки. Устанавливается только для соединений TLS. Установите перед выполнением сценария —tls-verify . Эта переменная аналогична  tls_id_{n}  , за исключением того, что поля темы компонента X509 разбиты на части, и в значениях этих полей не происходит переназначения строк (за исключением переназначения управляющих символов на «_»).Например, следующие переменные будут установлены на сервере OpenVPN с использованием образца сертификата клиента в образцах ключей (client.crt). Обратите внимание, что уровень проверки равен 0 для сертификата клиента и 1 для сертификата ЦС.

    [email protected]
  X509_0_CN=Тестовый клиент
  X509_0_O=OpenVPN-ТЕСТ
  X509_0_ST=Н/П
  X509_0_C=кг
  [email protected]
  X509_1_O=OpenVPN-ТЕСТ
  X509_1_L=БИШКЕК
  X509_1_ST=Н/П
  X509_1_C=кг
    

  OpenVPN позволяет включать файлы в основную конфигурацию для —ca, —cert, —dh, —extra-certs, —key, —pkcs12, —secret,   —crl-verify, —http-proxy-user-pass, —tls-auth и —tls-crypt .

  Каждый встроенный файл начинается со строки и заканчивается строкой

  Вот пример использования встроенного файла

    <сертификат>
  -----НАЧАТЬ СЕРТИФИКАТ-----
  [...]
  -----КОНЕЦ СЕРТИФИКАТА-----
  
    

  При использовании функции встроенного файла с —pkcs12 встроенный файл должен иметь кодировку base64. Кодирование файла .p12 в base64 можно выполнить, например, с помощью OpenSSL, запустив openssl base64 -in input.стр.12

  SIGHUP

  Заставляет OpenVPN закрыть все TUN/TAP и сетевые подключения, перезапустить, повторно прочитать файл конфигурации (если есть) и снова открыть TUN/TAP и сетевые подключения.

  SIGUSR1

  Аналогично SIGHUP, , за исключением того, что не нужно повторно читать файл конфигурации и, возможно, не закрывать и повторно открывать устройство TUN/TAP, повторно читать файлы ключей, сохранять локальный IP-адрес/порт или сохранять последний аутентифицированный удаленный IP-адрес. /port на основе параметров —persist-tun, —persist-key, —persist-local-ip, и —persist-remote-ip соответственно (см. выше).Этот сигнал также может генерироваться внутренним образом по условию тайм-аута, управляемому параметром —ping-restart .

  Этот сигнал в сочетании с —persist-remote-ip,  может быть отправлен при изменении основных параметров сетевого интерфейса узла, например, когда узел является DHCP-клиентом и ему назначается новый IP-адрес. См. —ipchange  выше для получения дополнительной информации.

  SIGUSR2

  Заставляет OpenVPN отображать текущую статистику (в файл системного журнала, если используется —daemon , или в стандартный вывод в противном случае).

  SIGINT, SIGTERM

  Вызывает изящный выход из OpenVPN.

  Если вы используете Linux 2.4.7 или выше, возможно, у вас уже установлен драйвер TUN/TAP. Если это так, есть еще несколько вещей, которые вам нужно сделать:

  Сделать устройство: mknod /dev/net/tun c 10 200

  Драйвер загрузки: modprobe tun  

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

  Настройка TUN/TAP:

  Если вы используете Linux 2.4 или выше, создайте узел устройства tun и загрузите модуль tun:

  мкнод /dev/net/tun c 10 200

  Модуль modprobe

  Если вы установили из RPM, шаг mknod  можно пропустить, потому что установка RPM сделает это за вас.

  Поддерживается только Linux 2.4 и новее.

  Для других платформ обратитесь к файлу INSTALL по адресу https://openvpn.net/community-resources/the-standard-install-file-included-in-the-source-distribution/ для получения дополнительной информации.

  Настройка брандмауэра:

  Если между двумя машинами существуют брандмауэры, они должны быть настроены на переадресацию порта UDP 1194 в обоих направлениях. Если у вас нет контроля над брандмауэрами между двумя компьютерами, вы все равно сможете использовать OpenVPN, добавив —ping 15 к каждой из команд openvpn , используемых ниже в примерах (это приведет к тому, что каждый одноранговый узел будет отправлять ping-запрос UDP своему удаленному партнеру каждые 15 секунд, что заставит многие брандмауэры с отслеживанием состояния пересылать пакеты в обоих направлениях без явного правила брандмауэра).

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

  iptables -A ВВОД -i tun+ -j ПРИНЯТЬ

  Дополнительные сведения о настройке брандмауэров для использования с OpenVPN см. в разделе о брандмауэрах ниже.

  Настройка VPN-адреса:

  Для нашего примера две наши машины будут называться bob.example.com и alice.пример.com.  Если вы создаете VPN через Интернет, замените bob.example.com и alice.example.com на имя хоста в Интернете или IP-адрес, которые каждая машина будет использовать для связи друг с другом через Интернет.

  Теперь выберем конечные точки туннеля. Конечные точки туннеля — это частные IP-адреса, которые имеют значение только в контексте VPN. Каждая машина будет использовать конечную точку туннеля другой машины для доступа к ней через VPN. В нашем примере конечная точка туннеля для bob.example.com будет 10.4.0.1, а alice.example.com — 10.4.0.2.

  После установки VPN вы, по сути, создали безопасный альтернативный путь между двумя хостами, который адресуется с помощью конечных точек туннеля. Вы можете контролировать, какой сетевой трафик проходит между хостами (а) через VPN или (б) независимо от VPN, выбирая, использовать ли (а) адрес конечной точки VPN или (б) общедоступный интернет-адрес для доступа к удаленному хозяин. Например, если вы находитесь на bob.example.com, и вы хотите подключиться к alice.example.com через ssh без использования VPN (поскольку ssh имеет собственную встроенную защиту), вы должны использовать команду ssh alice.example.com.  Однако в том же сценарии вы также можете использовать команду telnet 10.4.0.2  для создания сеанса telnet с alice.example.com через VPN, который будет использовать VPN для защиты сеанса, а не ssh.

  Вы можете использовать любой адрес для конечных точек туннеля, но убедитесь, что это частные адреса (например, те, которые начинаются с 10 или 192.168) и что они не являются частью какой-либо существующей подсети в сетях любого узла, если только вы не используете мост. Если вы используете адрес, который является частью вашей локальной подсети для любой из конечных точек туннеля, вы получите странную петлю обратной связи.

  Пример 1: Простой туннель без защиты

  На бобе:

  openvpn —remote alice.example.com —dev tun1 —ifconfig 10.4.0.1 10.4.0.2 —verb 9

  На Алисе:

  openvpn —удаленный боб.example.com —dev tun1 —ifconfig 10.4.0.2 10.4.0.1 —verb 9

  Теперь проверьте, работает ли туннель, отправив эхо-запрос через туннель.

  На бобе:

  эхо-запрос 10.4.0.2

  На Алисе:

  эхо-запрос 10.4.0.1

  Параметр —verb 9 выводит подробный вывод, аналогичный программе tcpdump . Опустите параметр  —verb 9  , чтобы OpenVPN работал тихо.

  Пример 2: Туннель со статическим ключом безопасности (т. е. с использованием предварительно общего секрета)

  Сначала создайте статический ключ на bob.

  openvpn —genkey —секретный ключ

  Эта команда создаст файл случайного ключа с именем key  (в формате ascii). Теперь скопируйте ключ Алисе через безопасный носитель, например, с помощью программы scp .

  На бобе:

  openvpn —удаленная Алиса.example.com —dev tun1 —ifconfig 10.4.0.1 10.4.0.2 —verb 5 —secret key

  На Алисе:

  openvpn —remote bob.example.com —dev tun1 —ifconfig 10.4.0.2 10.4.0.1 —verb 5 —секретный ключ

  Теперь проверьте, работает ли туннель, отправив эхо-запрос через туннель.

  На бобе:

  эхо-запрос 10.4.0.2

  На Алисе:

  эхо-запрос 10.4.0.1

  Пример 3: Туннель с полной безопасностью на основе TLS

  Для этого теста мы назначим bob в качестве клиента TLS и alice в качестве сервера TLS. Обратите внимание, что обозначение клиента или сервера имеет значение только для подсистемы TLS. Это не имеет никакого отношения к одноранговой модели связи OpenVPN на основе UDP.

  Сначала создайте отдельную пару сертификат/ключ для Боба и Алисы (см. выше, где —cert обсуждается для получения дополнительной информации). Затем создайте параметры Диффи-Хеллмана (см. выше, где —dh обсуждается для получения дополнительной информации). Вы также можете использовать прилагаемые тестовые файлы client.crt, client.key, server.crt, server.ключ и ca.crt. Файлы .crt — это сертификаты/открытые ключи, файлы .key — закрытые ключи, а ca.crt — это центр сертификации, подписавший и client.crt, и server.crt. Для параметров Диффи Хеллмана вы можете использовать прилагаемый файл dh2024.pem. Обратите внимание, что все сертификаты и ключи клиентов, серверов и центров сертификации, включенные в дистрибутив OpenVPN, полностью небезопасны и должны использоваться только для тестирования.

  На бобе:

  openvpn —удаленная Алиса.example.com —dev tun1 —ifconfig 10.4.0.1 10.4.0.2 —tls-client —ca ca.crt —cert client.crt —key client.key —reneg-sec 60 —verb 5

  На Алисе:

  openvpn —remote bob.example.com —dev tun1 —ifconfig 10.4.0.2 10.4.0.1 —tls-server —dh dh2024.pem —ca ca.crt —cert server.crt —key server.key —reneg-sec 60 —verb 5

  Теперь проверьте, работает ли туннель, отправив эхо-запрос через туннель.

  На бобе:

  пинг 10.4.0.2

  На Алисе:

  эхо-запрос 10.4.0.1

  Обратите внимание на параметр —reneg-sec 60 , который мы использовали выше. Это говорит OpenVPN пересматривать ключи канала данных каждую минуту. Поскольку мы использовали —verb 5 выше, вы будете видеть информацию о состоянии при каждом новом согласовании ключа.

  Для производственных операций интервал повторного согласования ключа в 60 секунд, вероятно, является слишком частым. Опустите параметр —reneg-sec 60 , чтобы использовать интервал повторного согласования ключа OpenVPN по умолчанию, равный одному часу.

  Маршрутизация:

  Предполагая, что вы можете отправить эхо-запрос через туннель, следующим шагом будет маршрутизация реальной подсети через защищенный туннель. Предположим, что у Боба и Алисы есть по два сетевых интерфейса, один из которых подключен к Интернету, а другой — к частной сети. Наша цель — безопасно соединить обе частные сети. Предположим, что частная подсеть Боба — 10.0.0.0/24, а Алисы — 10.0.1.0/24.

  Сначала убедитесь, что IP-переадресация включена на обоих узлах. В Linux включите маршрутизацию:

  эхо 1 > /proc/sys/net/ipv4/ip_forward

  и включить пересылку пакетов TUN через брандмауэр:

  iptables -A ВПЕРЕД -i tun+ -j ПРИНЯТЬ

  На бобе:

  маршрут добавить -сеть 10.0.1.0 сетевая маска 255.255.255.0 гвт 10.4.0.2

  На Алисе:

  маршрут добавить -net 10.0.0.0 маска сети 255.255.255.0 gw 10.4.0.1

  Теперь любой компьютер в подсети 10.0.0.0/24 может получить доступ к любому компьютеру в подсети 10.0.1.0/24 через безопасный туннель (или наоборот).

  В производственной среде вы можете поместить команды route в скрипт и выполнить их с параметром  —up  .

  Использование OpenVPN одного UDP-порта делает его довольно удобным для брандмауэра.Вы должны добавить запись в правила своего брандмауэра, чтобы разрешить входящие пакеты OpenVPN. В Linux 2.4+:

  iptables -A INPUT -p udp -s 1.2.3.4 —dport 1194 -j ПРИНЯТЬ

  Это позволит принимать входящие пакеты на UDP-порт 1194 (UDP-порт OpenVPN по умолчанию) от однорангового узла OpenVPN с адресом 1.2.3.4.

  Если вы используете аутентификацию пакетов на основе HMAC (по умолчанию в любом из безопасных режимов OpenVPN), наличие фильтра брандмауэра на исходном адресе можно считать необязательным, поскольку аутентификация пакетов HMAC является гораздо более безопасным методом проверки подлинности пакета. источник.В этом случае:

  iptables -A INPUT -p udp —dport 1194 -j ПРИНЯТЬ

  было бы достаточно и не сделало бы хост негибким по отношению к его одноранговому узлу, имеющему динамический IP-адрес.

  OpenVPN также хорошо работает на межсетевых экранах с отслеживанием состояния. В некоторых случаях вам может не понадобиться добавлять какие-либо статические правила в список брандмауэра, если вы используете брандмауэр с отслеживанием состояния, который умеет отслеживать соединения UDP. Если вы укажете —ping n,  OpenVPN будет гарантированно отправлять пакет своему партнеру не реже одного раза каждые n  секунд.Если n меньше тайм-аута соединения брандмауэра с отслеживанием состояния, вы можете поддерживать соединение OpenVPN неограниченное время без явных правил брандмауэра.

  Вам также следует добавить правила брандмауэра, чтобы разрешить входящий IP-трафик на устройства TUN или TAP, например:

  iptables -A ВВОД -i tun+ -j ПРИНЯТЬ

  , чтобы разрешить входящие пакеты от tun-устройств,

  iptables -A ВПЕРЕД -i tun+ -j ПРИНЯТЬ

  , чтобы разрешить пересылку входящих пакетов от устройств tun на другие хосты в локальной сети,

  iptables -A ВВОД -i нажмите+ -j ПРИНЯТЬ

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

  iptables -A ВПЕРЕД -i нажмите+ -j ПРИНЯТЬ

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

  Эти правила безопасны, если вы используете пакетную аутентификацию, поскольку никакие входящие пакеты не поступят на виртуальное устройство TUN или TAP, если они сначала не пройдут тест аутентификации HMAC.

  https://community.openvpn.net/openvpn/wiki/FAQ  

  Более подробное руководство по настройке OpenVPN в рабочей среде см. в OpenVPN HOWTO по адресу  https://openvpn.net/community-resources/how-to/  

  .

  Описание базового протокола OpenVPN см.  https://openvpn.сеть/сообщество-ресурсы/openvpn-протокол/  

  Веб-сайт OpenVPN находится по адресу  https://openvpn.net/

  .

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

  Сообщайте обо всех ошибках команде OpenVPN .

  Этот продукт включает программное обеспечение, разработанное в рамках проекта OpenSSL (  http://www.openssl.org/  )

  Для получения дополнительной информации о протоколе TLS см. http://www.ietf.org/rfc/rfc2246.txt

  Для получения дополнительной информации о библиотеке сжатия LZO в реальном времени см. http://www.oberhumer.com/opensource/lzo/

  Copyright (C) 2002-2018 OpenVPN Inc Эта программа является бесплатным программным обеспечением; вы можете распространять его и/или изменять в соответствии с условиями Стандартной общественной лицензии GNU версии 2, опубликованной Free Software Foundation.

  Джеймс Йонан

  Связи с брокером · Документация ActiveMQ Artemis

  Вместо ожидания подключения клиентов брокер может инициировать подключение к другой конечной точке по определенному протоколу.

  В настоящее время эта функция поддерживает только протокол AMQP. Однако в будущем он может быть расширен на другие протоколы.

  Соединения с брокером настраиваются элементом XML в файле конфигурации Broker.xml .

    <брокерские связи>
    ...
  
    

  Брокер ActiveMQ Artemis может инициировать соединения с использованием протокола AMQP. Это означает, что брокер может подключаться к другому серверу AMQP (не обязательно ActiveMQ Artemis) и создавать элементы для этого подключения.

  Чтобы определить соединение с брокером AMQP, добавьте элемент в элемент в файле конфигурации broker.xml . Например:

    <брокерские связи>
    
      ...
    
  
    

  • uri : tcp://host:myport (это обязательный аргумент)
  • имя : Имя соединения, используемого для целей управления
  • пользователь : Имя пользователя для подключения к конечной точке (это необязательный аргумент)
  • пароль : пароль для подключения к конечной точке (это необязательный аргумент)
  • retry-interval : Время ожидания в миллисекундах перед повторной попыткой подключения после ошибки.Значение по умолчанию: 5000 .
  • попыток повторного подключения : по умолчанию -1, что означает бесконечность
  • auto-start : Следует ли автоматически запускать соединение с брокером. По умолчанию true . Если false, необходимо вызвать операцию управления, чтобы запустить ее.

  Уведомление: Если автоматический запуск отключен для соединения с брокером, запуск соединения с брокером произойдет только после вызова метода управления startBrokerConnection(connectionName) на ServerController.

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

  При подключении к серверу AMQP поддерживаются следующие типы операций:

  • Зеркала
    • Брокер использует соединение AMQP с другим посредником, дублирует сообщения и отправляет подтверждения по сети.
  • Отправители
    • Сообщения, полученные в определенных очередях, передаются на другую конечную точку.
  • Получатели
    • Брокер получает сообщения от другой конечной точки.
  • Одноранговые узлы
    • Брокер создает отправителей и получателей на другой конечной точке, которая знает, как с ними обращаться. В настоящее время это реализуется Apache Qpid Dispatch.

  Можно определить, как будет происходить переподключение при соединении с брокером.

  Эти атрибуты доступны в XML-элементе amqp-соединения:

  • повторных попыток подключения: по умолчанию -1 (бесконечно). Сколько попыток будет сделано после неудачного подключения
  • retry-interval: по умолчанию 5000, в миллисекундах, ожидание между каждой повторной попыткой в ​​соединениях.

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

    <брокерские связи>
    
      ...
    
  
    

  Рис. 1. Соединение с брокером — повторное подключение и отработка отказа.

  В предыдущем примере показан случай сбоя подключения к серверу A. Система попытается подключиться к serverA, backupA и backupB, пока не подключится к одному из этих узлов.

  Зеркальное отображение

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

  Через зеркалирование отправляются следующие события:

  • Отправка сообщений
    • Сообщения, отправленные одному посреднику, будут "реплицированы" целевому посреднику.
  • Подтверждение сообщения
    • Подтверждения удаления сообщений на одном посреднике будут отправлены целевому посреднику.
    • Обратите внимание: если сообщение ожидает потребителя на целевом зеркале, подтверждение не будет успешным, и сообщение может быть доставлено обоими брокерами.
  • Создание очереди и адреса.
  • Удаление очереди и адреса.

  Зеркальная конфигурация

  Добавьте элемент в элемент , чтобы настроить зеркалирование для целевого брокера.

  Можно использовать следующие необязательные аргументы:

  • queue-removal : Указывает, отправляется ли событие удаления очереди или адреса. Значение по умолчанию — true .
  • сообщений-подтверждений : Указывает, отправляются ли подтверждения сообщений. Значение по умолчанию — true .
  • создание очереди : Указывает, отправляется ли событие создания очереди или адреса. Значение по умолчанию — true .

  Пример конфигурации зеркала показан ниже:

    <брокерские связи>
    
      <зеркало/>
    
  
    

  Сохранить и переслать очередь

  Зеркальные события всегда сохраняются в локальной очереди с префиксом «$ACTIVEMQ ARTEMIS_MIRROR », а затем объединяются с настроенным именем подключения к брокеру.

  Итак, в следующей конфигурации события зеркала будут храниться в очереди с именем "$ACTIVEMQ_ARTEMIS_MIRROR_brokerB".

    <брокер-соединение>
    
      <зеркало/>
    
  
    

  Затем эти сообщения передаются брокеру B:5672. Производитель по адресу $ACTIVEMQ_ARTEMIS_MIRROR_brokerB будет создан по отношению к brokerB. Если настроен менеджер безопасности, роли безопасности должны быть предоставлены пользователю в соединении с посредником.

  Обратите внимание, что очередь $ACTIVEMQ_ARTEMIS_MIRROR_brokerB на самом деле не существует на брокере B, поэтому она не будет видна в административной консоли.Целевой посредник будет обрабатывать эти сообщения соответственно как зеркальные события и выполнять соответствующие операции на целевом посреднике.

  Существующие сообщения

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

  Двойное зеркало (аварийное восстановление)

  ActiveMQ Artemis поддерживает автоматическое резервное зеркальное отображение. Каждое отправленное сообщение и каждое подтверждение асинхронно реплицируются на зеркальный брокер.

  На следующей диаграмме будет два сервера с именами DataCenter1 и DataCenter2. Чтобы иметь конфигурацию с двойным зеркалом, необходимо добавить соединение зеркального брокера в каждый файл broker.xml:

  .

  Рис. 2. Подключение брокера — аварийное восстановление.

  в DataCenter1, необходимо добавить следующий код в broker.xml:

    <брокерские связи>
     
        <зеркало/>
     
  
    

  Следующий xml должен быть добавлен в брокер DataCenter2.XML:

    <брокерские связи>
     
        <зеркало/>
     
  
    

  Соединения с посредником будут реплицировать отправки и подтверждения другому посреднику, независимо от того, откуда они были отправлены. Если сообщения отправляются на DC1 (DataCenter1), они будут автоматически переданы на DC2 (DataCenter2). Подтверждения сообщений, полученные на DC2, будут автоматически связаны с DC1.Единственное исключение из этого правила было бы, если бы на любом сервере уже были потребители с ожидающими сообщениями, где зеркальное подтверждение не предотвратит потребление сообщения обоими потребителями. Не рекомендуется иметь активных потребителей на обоих серверах.

  Пример

  В состав дистрибутива входит пример, показывающий конфигурацию двойного брокера (или аварийное восстановление) в разделе ./examples/features/broker-connection/disaster-recovery.

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

  Отправители и получатели

  Можно подключить посредник ActiveMQ Artemis к другой конечной точке AMQP, просто создав элемент подключения отправителя или получателя посредника.

  Для отправителя посредник создает получателя сообщений в очереди, которая отправляет сообщения на другую конечную точку AMQP.

  Для получателя посредник создает производителя сообщений по адресу, который получает сообщения от другой конечной точки AMQP.

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

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

  • совпадение адресов : Сопоставьте отправителя или получателя с конкретным адресом или набором адресов, используя выражение с подстановочными знаками
  • имя-очереди : настроить отправителя или получателя для конкретной очереди

  Некоторые примеры показаны ниже.

  Использование адресных выражений:

    <брокерские связи>
    
      
      
      <адрес получателя-match="remotequeues.#"/>
    
  
  
  <адреса>
    <адрес name="remotequeues.A">
      <любая передача>
        <имя очереди="remoteQueueA"/>
      
    
    <адрес имя="очереди.Б">
      <любая передача>
        <имя очереди="localQueueB"/>
      
    
  
    

  Использование имен очередей:

    <брокерские связи>
    
      <имя очереди получателя="remoteQueueA"/>
      <имя-очереди-отправителя="localQueueB"/>
    
  
  
  <адреса>
     <адрес name="remotequeues.A">
       <любая передача>
         <имя очереди="remoteQueueA"/>
       
     
     <адрес имя="очереди.Б">
       <любая передача>
         <имя очереди="localQueueB"/>
       
     
  
    

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

  Важно: Не создавайте отправителя и получателя для одного и того же адресата. Это создает бесконечный цикл отправки и получения.

  Сверстники

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

  Конфигурация однорангового узла заставляет ActiveMQ Artemis создавать пару отправителя и получателя для каждого пункта назначения, совпадающего в конфигурации соединения с посредником, при этом они имеют специальную конфигурацию, чтобы сообщить Qpid Dispatch о сотрудничестве с посредником.Это заменяет традиционную необходимость подключения, инициируемого маршрутизатором, и автоматических ссылок.

  Qpid Dispatch Router предлагает множество расширенных сетевых параметров, которые можно использовать вместе с ActiveMQ Artemis.

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

    <брокерские связи>
    
      
    
  
  
  <адреса>
     <адрес name="queues.A">
       <любая передача>
         <имя очереди="queues.A"/>
       
     
     <адрес name="queues.B">
       <любая передача>
         <имя очереди="queues.B"/>
       
     
  
    

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

  .

    адрес {
      префикс: очередь
      путевая точка: да
  }
    

  Для получения дополнительной информации см. документацию по обмену сообщениями через посредника для диспетчерского маршрутизатора Apache Qpid.

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

  Важно: Нет необходимости настраивать маршрутизатор с коннектором или автоматическими ссылками для связи с посредником.Конфигурация узла брокера заменяет эти аспекты использования путевой точки маршрутизатора.

  Рассмотрение адреса

  Настоятельно рекомендуется, чтобы адресное имя и имя очереди совпадали. Когда используется очередь с собственным именем (как в следующем примере), отправители и получатели всегда будут использовать имя адреса при создании удаленной конечной точки.

    <брокерские связи>
    
      
    
  
  <адреса>
    <адрес name="queues.A">
      <любая передача>
        
      
    
  
    

  В приведенном выше примере соединение брокера создаст отправителя AMQP в направлении "queues.A".

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

  Конфигурация • Akka HTTP

   источник копирования  #########################################
  # Справочный файл конфигурации akka-http-core #
  #########################################
  
  # Это эталонный файл конфигурации, содержащий все настройки по умолчанию.
  # Внесите свои изменения/переопределения в файл application.conf.
  
  # Версия Akka HTTP, сверенная с версией времени выполнения Akka HTTP.
  # Загружается из сгенерированного файла conf.
  включить "akka-http-версию"
  
  акка.http {
  
    сервер {
      # Значение заголовка `Server` по умолчанию для создания, если нет
      # в ответ был включен явный заголовок `Server`.
      # Если это значение является пустой строкой и заголовок не был включен в
      # запрос, заголовок `Server` вообще не будет отображаться.
      сервер-заголовок = akka-http/${akka.http.version}
  
      # "PREVIEW" функции, которые еще не полностью готовы к работе.
      # Эти флаги могут быть изменены или удалены между выпусками исправлений.
      предварительный просмотр {
        # Если этот параметр включен И akka-http2-support найден
        # в пути к классам `Http().newServerAt(...).bind` и `bindSync`
        # будет разрешено использовать HTTP/2.
        #
        # `Http().newServerAt(...).bindFlow` и `connectionSource()` не поддерживаются.
        включить-http2 = выкл.
      }
  
      # Время, по истечении которого бездействующее соединение будет автоматически закрыто.
      # Установите на `infinite`, чтобы полностью отключить тайм-ауты простоя соединения.
      тайм-аут бездействия = 60 с
  
      # Определяет период времени по умолчанию, в течение которого приложение должно
      # создать HttpResponse для любого полученного HttpRequest.# Тайм-аут начинает отсчитываться, когда *конец* запроса был
      # получено, поэтому даже потенциально длинные загрузки могут иметь короткий тайм-аут.
      # Установите значение `infinite`, чтобы полностью отключить проверку тайм-аута запроса.
      #
      # Убедитесь, что этот тайм-аут меньше тайм-аута простоя, иначе
      # тайм-аут простоя сработает первым и сбросит TCP-соединение
      # без ответа.
      #
      # Если этот параметр не отключен, уровень HTTP-сервера прикрепляет
      # Заголовок `Timeout-Access` к запросу, который включает
      # настройка периода тайм-аута и ответа на тайм-аут для каждого
      # запросить индивидуально.запрос-тайм-аут = 20 с
  
      # Период времени, в течение которого должен быть завершен процесс привязки TCP.
      тайм-аут привязки = 1 с
  
      # Порт по умолчанию для привязки HTTP-сервера, если порт явно не указан.
      http-порт по умолчанию = 80
  
      # Порт по умолчанию для привязки HTTPS-сервера, если порт явно не указан.
      порт по умолчанию https = 443
  
      # Период времени, в течение которого реализация HTTP-сервера будет поддерживать соединение открытым после
      # все данные доставлены на сетевой уровень. Этот параметр аналогичен параметру сокета SO_LINGER.
      # но включает не только сокет уровня ОС, но и сетевой стек Akka IO/Akka Streams.# Этот параметр является дополнительной мерой предосторожности, которая не позволяет клиентам поддерживать открытое соединение,
      # уже считается завершенным со стороны сервера.
      #
      # Если буферы сетевого уровня (включая буферы сетевого стека Akka Stream / Akka IO)
      # содержит больше данных, чем может быть передано клиенту за заданное время, когда сервер считает
      # чтобы завершить это соединение, клиент может столкнуться с сбросом соединения.
      #
      # Установите значение «бесконечно», чтобы отключить автоматическое закрытие соединения (что может привести к утечке соединений).задержка-тайм-аут = 1 мин.
  
      # Максимальное количество одновременно принятых подключений при привязке сервера с помощью
      # Методы `Http().newServerAt().bindXYZ()`.
      #
      # Этот параметр не применяется к методу `Http().bind`, который по-прежнему
      # доставлять неограниченный поток входящих подключений с обратным давлением.
      #
      # Обратите внимание, что этот параметр максимально ограничивает количество подключений.
      # Строго *не* гарантирует, что количество установленных TCP-соединений никогда не будет
      # превышаем лимит (но это будет примерно правильно), т.к. происходит обрыв соединения
      # асинхронно.Это также *не* гарантирует, что количество одновременно активных обработчиков
      # материализация потока никогда не превысит лимит по причине невозможности достоверно
      # определить, когда материализация закончилась.
      максимальное количество подключений = 1024
  
      # Максимальное количество запросов, которые принимаются (и отправляются
      # приложение) на одном единственном соединении перед первым запросом
      # должен быть завершен.
      # Входящие запросы, которые могут привести к превышению лимита конвейерной обработки
      # не считываются из сокета соединений, чтобы создать "противодавление"
      # к клиенту через управление потоком TCP.# Значение 1 отключает конвейерную обработку HTTP, так как только один запрос на
      # соединение может быть "открыто" (т.е. обрабатывается приложением) в любой момент
      # время. Установите более высокие значения, чтобы включить конвейерную обработку HTTP.
      # Это значение должно быть > 0 и <= 1024.
      предел конвейерной обработки = 1
  
      # Включает/отключает добавление заголовка `Remote-Address`
      # хранение клиентского (удаленного) IP-адреса.
      # Устарело с версии 10.2.0: вместо этого используйте `remote-address-attribute`.
      заголовок удаленного адреса = выкл.
  
      # Включает/отключает добавление атрибута удаленного адреса в HttpRequest
      # хранение клиентского (удаленного) IP-адреса.Это предпочтительнее, чем `remote-address-header`
      # потому что его нельзя спутать с настоящим заголовком.
      удаленный-адрес-атрибут = выкл.
  
      # Включает/отключает добавление заголовка Raw-Request-URI, содержащего
      # исходный необработанный URI запроса в том виде, в каком его отправил клиент.
      исходный запрос-uri-заголовок = выкл.
  
      # Включает/отключает автоматическую обработку запросов HEAD.
      # Если этот параметр включен, сервер отправляет запросы HEAD как GET
      # запрашивает приложение и автоматически удаляет все сообщения
      # тела из исходящих ответов.# Обратите внимание, что даже если этот параметр отключен, сервер никогда не будет отправлять
      # вывод тела сообщений в ответ на запросы HEAD.
      прозрачные запросы головы = выкл.
  
      # Включает/отключает возврат более подробных сообщений об ошибках в
      # клиент в ответе об ошибке.
      # Должен быть отключен для браузерных API из-за риска XSS-атак.
      # и (вероятно) включен для внутренних или небраузерных API.
      # Обратите внимание, что akka-http всегда будет создавать сообщения журнала, содержащие полный
      # сведения об ошибке.подробные сообщения об ошибках = выкл.
  
      # Начальный размер буфера для отображения заголовков ответа.
      # Может использоваться для тонкой настройки производительности рендеринга ответов, но, вероятно,
      # не нужно возиться в большинстве приложений.
      подсказка размера заголовка ответа = 512
  
      # Запрашиваемая максимальная длина очереди входящих подключений.
      # Если сервер занят, а отставание заполнено, ОС начнет падать
      # SYN-пакеты и попытки подключения могут быть неудачными. Обратите внимание, что отставание
      # размер обычно является только подсказкой максимального размера для ОС, и ОС может
      # дополнительно ограничить число на основе глобальных ограничений.отставание = 100
  
      # Если этот параметр пуст, сервер принимает только запросы, содержащие
      # непустой заголовок `Host`. В противном случае он отвечает «400 Bad Request».
      # Установите непустое значение, которое будет использоваться вместо отсутствующего или пустого `Host`
      # заголовок, чтобы сервер принимал такие запросы.
      # Обратите внимание, что сервер никогда не примет запрос HTTP/1.1 без `Host`
      # заголовок, т.е. этот параметр влияет только на запросы HTTP/1.1 с пустым
      # Заголовок `Host`, а также HTTP/1.0 запросов.
      # Примеры: `www.spray.io` или `example.com:8080`
      заголовок хоста по умолчанию = ""
  
      # Параметры сокета для установки прослушивающего сокета. Если оставить настройку
      # undefined, он будет использовать то, что установлено по умолчанию в системе.
      параметры сокета {
        размер так-получения-буфера = не определен
        размер буфера отправки = не определено
        так-повторно-адрес = не определено
        так-трафик-класс = неопределенный
        TCP-поддержка = не определено
        tcp-oob-inline = не определено
        TCP-без задержки = не определено
      }
  
      # Когда изящное завершение включено и используется с дедлайном,
      # после истечения крайнего срока на ожидающие запросы будет дан ответ с "завершающим" http-ответом,
      # вместо доставки этих запросов пользователю-обработчику.# Этот ответ настраивается здесь с помощью конфигурации или с помощью кода в случае более сложного (например, с сущностью ответа)
      # требуется ответ.
      #
      окончание-крайний-превышенный-ответ {
        # Код состояния «завершающего» ответа, который будет автоматически отправлен на ожидающие запросы после превышения крайнего срока завершения.
        статус = 503 # СервисНедоступен
      }
  
      # Изменить, чтобы настроить параметры синтаксического анализа только на стороне сервера.
      разбор {
        # по умолчанию никаких переопределений, см. `akka.http.parsing` для значений по умолчанию
  
        # Настройки парсинга для конкретного сервера:
  
        # Максимальная длина содержимого по умолчанию, которая не должна превышаться входящим запросом.
        # Можно изменить во время выполнения (на большее или меньшее значение) с помощью метода `HttpEntity::withSizeLimit`.
        # Обратите внимание, что установка большого значения не обязательно является проблемой, так как все потоковые операции
        # всегда имеют правильное противодавление.
        # Тем не менее, вы можете захотеть применить некоторые ограничения, чтобы предотвратить потребление одним клиентом
        # чрезмерное количество ресурсов сервера.#
        # Установите значение `infinite`, чтобы полностью отключить проверку длины объекта. (Даже тогда вы все равно можете применить один
        # программно через `withSizeLimit`.)
        максимальная длина содержимого = 8 м
  
        # Когда запрос настолько искажен, что мы не можем создать из него RequestContext,
        # обычная обработка исключений не применяется, а обработка ошибок по умолчанию
        # применяется, который имеет доступ только к ошибке синтаксического анализа, а не к фактическому запросу.
        # Чтобы настроить этот ответ на ошибку, задайте для обработчика ошибок полное доменное имя
        # реализация акка.http.ParsingErrorHandler
        обработчик ошибок = "akka.http.DefaultParsingErrorHandler$"
      }
  
      # Включает/отключает ведение журнала незашифрованного HTTP-трафика в и из HTTP
      # сервер для отладки.
      #
      # Примечание: используйте с осторожностью. Регистрация незашифрованного трафика данных может привести к раскрытию секретных данных.
      #
      # Входящий и исходящий трафик будет записываться в шестнадцатеричном формате. Чтобы включить ведение журнала,
      # указать количество байтов для регистрации на блок данных (фактическое разделение зависит
      # о деталях реализации и сетевых условиях и должен рассматриваться как
      # произвольный).#
      # Для регистрации на стороне клиента см. akka.http.client.log-unencrypted-network-bytes.
      #
      # `off`: сообщения журнала не создаются
      # Int : определяет, сколько байтов должно быть записано на блок данных.
      log-unencrypted-network-bytes = выкл.
  
      # Отмена в HTTP-потоках задерживается на это время, чтобы предотвратить состояние гонки между отменами
      # и завершение/сбой потока. В большинстве случаев выбранное здесь значение не должно иметь значения, потому что
      # Потоки HTTP представляют собой циклы, в которых завершение и сбои должны распространяться немедленно и усложнять обработку
      # отмены избыточны.#
      # В большинстве случаев не должно быть причин для изменения этого параметра.
      #
      # Установите 0, чтобы отключить задержку.
      задержка отмены потока = 100 миллисекунд
  
      http2 {
        # Максимальное количество запросов на соединение, одновременно отправляемых обработчику запросов.
        # Это ограничение вступает в силу, как только соединение между узлами установлено. Обеспечение
        # ограничение еще до завершения обмена SETTINGS/SETTINGS_ACK означает
        # что мы будем отказываться от лишних потоков/запросов, отправленных клиентом сразу после
        # соединение было установлено, но до того, как оно получило наши НАСТРОЙКИ.максимальное количество одновременных потоков = 256
  
        # Максимальное количество байтов, которые можно получить от объекта запроса в одном фрагменте.
        #
        # Причина ограничения этого количества (вместо доставки всех буферизованных данных для потока) заключается в том, что
        # объем данных во внутренних буферах будет управлять противодавлением и управлением потоком на уровне HTTP/2. Больше
        # куски означают, что считыватель сущностей пользовательского уровня должен будет буферизовать все эти данные, если он не может прочитать их за один раз.
        # идти. В этом случае реализация не сможет противодавить дальнейшим данным, потому что она не знает о
        # этот буфер пользовательского уровня.запрос-сущность-размер блока = 65536 б
  
        # Количество байтов данных запроса, которые реализация HTTP/2 может буферизовать внутри каждого соединения. Бесплатно
        # пространство в этом буфере сообщается партнеру с помощью сообщений управления потоком HTTP/2 для противодавления данных, если они
        # читается недостаточно быстро.
        #
        # При отсутствии противодавления это значение будет ограничивать объем данных в полете. Возможно нужно увеличить
        # для соединений с высокой пропускной способностью продукта задержки.
        #
        # Существует связь между размером буфера на уровне входящего соединения и размером буфера на уровне входящего потока:
        # Если размер буфера уровня входящего соединения < размер буфера уровня входящего потока * число_потоков, то
        # Возможна блокировка заголовка строки между разными потоками в одном и том же соединении.размер буфера уровня входящего соединения = 10 МБ
  
        # Количество байтов данных запроса, которые реализация HTTP/2 может буферизовать внутри каждого потока. Свободное место
        # в этом буфере передается партнеру с помощью сообщений управления потоком HTTP/2 для противодействия данным, если это не так
        # читать достаточно быстро.
        #
        # Когда противодавление отсутствует, это значение будет ограничивать количество передаваемых данных на поток. Возможно, потребуется
        # быть увеличено для соединений с высокой пропускной способностью продукта задержки.размер буфера уровня входящего потока = 512 КБ
  
        # Для входящих запросов инфраструктура собирает как минимум заданное количество байт перед отправкой HttpRequest.
        # Если все данные запроса получены до или после достижения порога, данные объекта отправляются как строгий объект
        # что позволяет более эффективно обрабатывать данные запроса без привлечения потоков.
        #
        # Если задано значение 0, запрос отправляется немедленно и всегда содержит поток данных.# Вы можете использовать значение `1` для создания строгой сущности, если запрос содержит не более одного фрейма данных и потокового
        # объект в противном случае.
        #
        # Если `min-collect-strict-entity-size > 0` и запрос отменен (RST_STREAM) до того, как будет собрано достаточно данных и запрос
        # отправляется, то запрос молча отбрасывается.
        #
        # Чтобы избежать взаимоблокировок управления потоком, значение должно быть меньше или равно `incoming-stream-level-buffer-size`
        # и `размер буфера уровня входящего соединения / максимальное количество одновременных потоков`.#
        # Обратите внимание: если включено, запросы, ожидающие данных (endStream = false для HEADERS), но никогда не получавшие фрейм DATA, никогда не будут
        # отправлено. В обычном контексте HTTP это редкость. Это потребует, чтобы клиент сначала ожидал данные с сервера.
        # перед отправкой любых собственных данных.
        минимальный размер сбора строгого объекта = 0
  
        # Максимальное количество исходящих управляющих кадров для буферизации, когда одноранговый узел не считывает свое TCP-соединение до
        # обратное давление на входящие кадры.#
        # При исправном HTTP/2-соединении этот параметр не должен иметь большого эффекта, поскольку контрольные фреймы имеют приоритет над
        # кадры данных и не должны буферизоваться в течение длительного времени.
        #
        # Ограничение необходимо для того, чтобы злонамеренный одноранговый узел не запрашивал буферизацию исходящих кадров управления (например, отправляя PING)
        # без чтения фреймов, что в конечном итоге приводит к ситуации нехватки памяти. При установленном лимите реализация
        # останавливает чтение входящих кадров, когда количество исходящих управляющих кадров достигает заданного значения.Таким образом, злоумышленник
        # не может продолжать обмен данными без предварительного освобождения места в окне TCP, опустошая буферизованные кадры управления.
        #
        # Пример такой атаки см. в CVE-2019-9512.
        #
        # Обратите внимание, что затрагиваются только кадры управления, поскольку кадры данных, напротив, покрываются управлением потоком HTTP/2.
        размер буфера исходящего управляющего кадра = 1024
  
        # Включить подробное ведение журнала отладки для всех входящих и исходящих кадров
        лог-кадры = ложь
  
        # Когда данные не передаются ни в одном направлении, но есть активные потоки, отправьте пинг-кадр HTTP/2 с этим начальным
        # задержка и последующий интервал, чтобы убедиться, что соединение поддерживается, 0s отключает отправку кадров ping.пинг-интервал = 0 с
  
        # Сбой соединения, если отправленный пинг не подтвержден в течение этого тайм-аута.
        # Когда используется нулевой интервал пинга, если он установлен, значение должно делиться без остатка на меньшее или равное интервалу пинга.
        тайм-аут пинга = 0 с
      }
  
      веб-сокет {
        # периодическая поддержка активности может быть реализована с помощью отправки кадров Ping
        # на что другая сторона должна ответить кадром Pong,
        # или отправив кадр Pong, который служит однонаправленным сердцебиением.# Допустимые значения:
        # ping - по умолчанию, для двунаправленного ping/pong keep-alive пульсации
        # pong - для однонаправленного сердцебиения pong keep-alive
        #
        # Также можно предоставить полезную нагрузку для каждого сообщения пульса,
        # этот параметр можно настроить программно, изменив настройки веб-сокета.
        # См.: https://doc.akka.io/docs/akka-http/current/server-side/websocket-support.html.
        периодический-поддерживающий-режим = пинг
  
        # Интервал отправки периодических сообщений keep-alive
        # Отправленный фрейм будет настроен в akka.http.server.websocket.periodic-keep-alive-mode
        # `infinite` по умолчанию или длительность, которая является максимальным интервалом простоя, после которого должен быть отправлен кадр проверки активности
        # Значение `infinite` означает, что *никаких* контрольных импульсов не будет отправлено, как: "разрешенное время простоя бесконечно"
        периодическая поддержка активности макс. бездействие = бесконечный
  
        # Включить подробное ведение журнала отладки для всех входящих и исходящих кадров
        лог-кадры = ложь
      }
    }
  
    #клиент-настройки
    клиент {
      # Значение заголовка `User-Agent` по умолчанию для создания, если нет
      # в запрос включен явный заголовок `User-Agent`.# Если это значение является пустой строкой и заголовок не был включен в
      # запрос, заголовок `User-Agent` не будет отображаться вообще.
      user-agent-header = akka-http/${akka.http.version}
  
      # Период времени, в течение которого должен быть завершен процесс соединения TCP.
      время ожидания подключения = 10 с
  
      # Время, по истечении которого бездействующее соединение будет автоматически закрыто.
      # Установите на `infinite`, чтобы полностью отключить таймауты простоя.
      тайм-аут бездействия = 60 с
  
      # Начальный размер буфера для отображения заголовков запроса.# Может использоваться для тонкой настройки производительности рендеринга запросов, но, вероятно,
      # не нужно возиться в большинстве приложений.
      подсказка размера заголовка запроса = 512
  
      # Параметры сокета для установки прослушивающего сокета. Если оставить настройку
      # undefined, он будет использовать то, что установлено по умолчанию в системе.
      параметры сокета {
        размер так-получения-буфера = не определен
        размер буфера отправки = не определено
        так-повторно-адрес = не определено
        так-трафик-класс = неопределенный
        TCP-поддержка = не определено
        tcp-oob-inline = не определено
        TCP-без задержки = не определено
      }
  
      # Параметры https-прокси клиента.При использовании ClientTransport.httpsProxy() с учетными данными или без них
      # хост/порт должен быть либо передан явно, либо указан здесь. Если хост не указан, прокси не будет использоваться.
      прокси {
        https {
          хост = ""
          порт = 443
        }
      }
  
      # Изменить, чтобы настроить параметры синтаксического анализа только на стороне клиента.
      разбор {
        # по умолчанию никаких переопределений, см. `akka.http.parsing` для значений по умолчанию
  
        # Максимальная длина содержимого по умолчанию, которую не должны превышать входящие сущности ответа.# Можно изменить во время выполнения (на большее или меньшее значение) с помощью метода `HttpEntity::withSizeLimit`.
        # Обратите внимание, что установка большого значения не обязательно является проблемой, так как все потоковые операции
        # всегда имеют правильное противодавление.
        #
        # На стороне клиента это ограничение отключено по умолчанию, поскольку клиент контролирует запросы, которые он выполняет.
        #
        # Установите значение `infinite`, чтобы полностью отключить проверку длины объекта. (Даже тогда вы все равно можете применить один
        # программно через `withSizeLimit`.)
        максимальная длина содержимого = бесконечная
      }
  
      # Включает/отключает ведение журнала незашифрованного HTTP-трафика в и из HTTP
      # клиент для отладки.
      #
      # Примечание: используйте с осторожностью. Регистрация незашифрованного трафика данных может привести к раскрытию секретных данных.
      #
      # Входящий и исходящий трафик будет записываться в шестнадцатеричном формате. Чтобы включить ведение журнала,
      # указать количество байтов для регистрации на блок данных (фактическое разделение зависит
      # о деталях реализации и сетевых условиях и должен рассматриваться как
      # произвольный).#
      # Для регистрации на стороне сервера см. akka.http.server.log-unencrypted-network-bytes.
      #
      # `off`: сообщения журнала не создаются
      # Int : определяет, сколько байтов должно быть записано на блок данных.
      log-unencrypted-network-bytes = выкл.
  
      #клиент-настройки
      // FIXME: унифицировать с серверной частью (путем импорта или аналогично парсингу)
      http2 {
        # Максимальное количество запросов на соединение, одновременно отправляемых обработчику запросов.
        # Это ограничение вступает в силу, как только соединение между узлами установлено.Обеспечение
        # ограничение еще до завершения обмена SETTINGS/SETTINGS_ACK означает
        # что мы будем отказываться от дополнительных потоков/push-обещаний, которые были отправлены клиентом сразу после
        # соединение было установлено, но до того, как оно получило наши НАСТРОЙКИ.
        максимальное количество одновременных потоков = 256
  
        # Максимальное количество байтов, которые можно получить от объекта запроса в одном фрагменте.
        #
        # Причина ограничения этого количества (вместо доставки всех буферизованных данных для потока) заключается в том, что
        # объем данных во внутренних буферах будет управлять противодавлением и управлением потоком на уровне HTTP/2.Больше
        # куски означают, что считыватель сущностей пользовательского уровня должен будет буферизовать все эти данные, если он не может прочитать их за один раз.
        # идти. В этом случае реализация не сможет противодавить дальнейшим данным, потому что она не знает о
        # этот буфер пользовательского уровня.
        запрос-сущность-размер блока = 65536 б
  
        # Количество байтов данных запроса, которые реализация HTTP/2 может буферизовать внутри каждого соединения. Бесплатно
        # пространство в этом буфере сообщается партнеру с помощью сообщений управления потоком HTTP/2 для противодавления данных, если они
        # читается недостаточно быстро.#
        # При отсутствии противодавления это значение будет ограничивать объем данных в полете. Возможно нужно увеличить
        # для соединений с высокой пропускной способностью продукта задержки.
        #
        # Существует связь между размером буфера на уровне входящего соединения и размером буфера на уровне входящего потока:
        # Если размер буфера уровня входящего соединения < размер буфера уровня входящего потока * число_потоков, то
        # Возможна блокировка заголовка строки между разными потоками в одном и том же соединении.размер буфера уровня входящего соединения = 10 МБ
  
        # Количество байтов данных запроса, которые реализация HTTP/2 может буферизовать внутри каждого потока. Свободное место
        # в этом буфере передается партнеру с помощью сообщений управления потоком HTTP/2 для противодействия данным, если это не так
        # читать достаточно быстро.
        #
        # Когда противодавление отсутствует, это значение будет ограничивать количество передаваемых данных на поток. Возможно, потребуется
        # быть увеличено для соединений с высокой пропускной способностью продукта задержки.размер буфера уровня входящего потока = 512 КБ
  
        # Максимальное количество исходящих управляющих кадров для буферизации, когда одноранговый узел не считывает свое TCP-соединение до
        # обратное давление на входящие кадры.
        #
        # При исправном HTTP/2-соединении этот параметр не должен иметь большого эффекта, поскольку контрольные фреймы имеют приоритет над
        # кадры данных и не должны буферизоваться в течение длительного времени.
        #
        # Ограничение необходимо для того, чтобы злонамеренный одноранговый узел не запрашивал буферизацию исходящих управляющих кадров (т.г. путем отправки PING)
        # без чтения фреймов, что в конечном итоге приводит к ситуации нехватки памяти. При установленном лимите реализация
        # останавливает чтение входящих кадров, когда количество исходящих управляющих кадров достигает заданного значения. Таким образом, злоумышленник
        # не может продолжать обмен данными без предварительного освобождения места в окне TCP, опустошая буферизованные кадры управления.
        #
        # Пример такой атаки см. в CVE-2019-9512.
        #
        # Обратите внимание, что затрагиваются только кадры управления, поскольку кадры данных, напротив, покрываются управлением потоком HTTP/2.размер буфера исходящего управляющего кадра = 1024
  
        # Включить подробное ведение журнала отладки для всех входящих и исходящих кадров
        лог-кадры = ложь
  
        # Когда данные не передаются ни в одном направлении, но есть активные потоки, отправьте пинг-кадр HTTP/2 с этим начальным
        # задержка и последующий интервал, чтобы убедиться, что соединение поддерживается, 0s отключает отправку кадров ping.
        пинг-интервал = 0 с
  
        # Сбой соединения, если отправленный пинг не подтвержден в течение этого тайм-аута.# Когда используется нулевой интервал пинга, если он установлен, значение должно делиться без остатка на меньшее или равное интервалу пинга.
        тайм-аут пинга = 0 с
  
        # Максимальное количество попыток подключения
        # прежде чем сдаться и вернуть ошибку.
        # Установите в ноль, чтобы повторять бесконечное количество раз.
        максимальное количество постоянных попыток = 0
  
        # Запуск отсрочки перед повторным подключением при сбое постоянного клиентского подключения HTTP/2
        # см. `akka.http.host-connection-pool.base-connection-backoff` для подробностей о механизме отсрочки.base-connection-backoff = ${akka.http.host-connection-pool.base-connection-backoff}
  
        # Максимальная отсрочка между попытками повторного подключения при сбое постоянного клиентского соединения HTTP/2
        # см. `akka.http.host-connection-pool.max-connection-backoff` для подробностей о механизме отсрочки.
        max-connection-backoff = ${akka.http.host-connection-pool.max-connection-backoff}
  
        # При корректном закрытии клиента HTTP/2 ждать не более `completion-timeout` для работы в полете
        # запросов для завершения.время ожидания завершения = 3 с
  
      }
  
      #клиент-настройки
      веб-сокет {
        # периодическая поддержка активности может быть реализована с помощью отправки кадров Ping
        # на что другая сторона должна ответить кадром Pong,
        # или отправив кадр Pong, который служит однонаправленным сердцебиением.
        # Допустимые значения:
        # ping - по умолчанию, для двунаправленного ping/pong keep-alive пульсации
        # pong - для однонаправленного сердцебиения pong keep-alive
        #
        # См. https://tools.ietf.org/html/rfc6455#section-5.5.2
        # и https://tools.ietf.org/html/rfc6455#section-5.5.3 для получения дополнительной информации
        периодический-поддерживающий-режим = пинг
  
        # Интервал отправки периодических сообщений keep-alive
        # Отправляемый фрейм будет настроен в akka.http.server.websocket.periodic-keep-alive-mode
        # `infinite` по умолчанию или длительность, которая является максимальным интервалом простоя, после которого должен быть отправлен кадр проверки активности
        периодическая поддержка активности макс. бездействие = бесконечный
  
        # Включить подробное ведение журнала отладки для всех входящих и исходящих кадров
        лог-кадры = ложь
      }
  
      # Отмена в HTTP-потоках задерживается на это время, чтобы предотвратить состояние гонки между отменами
      # и завершение/сбой потока.В большинстве случаев выбранное здесь значение не должно иметь значения, потому что
      # Потоки HTTP представляют собой циклы, в которых завершение и сбои должны распространяться немедленно и усложнять обработку
      # отмены избыточны.
      #
      # В большинстве случаев не должно быть причин для изменения этого параметра.
      #
      # Установите 0, чтобы отключить задержку.
      задержка отмены потока = 100 миллисекунд
    }
    #клиент-настройки
  
    #pool-настройки
    пул хост-соединений {
      # Максимальное количество параллельных подключений пула подключений к
      # разрешена установка конечной точки с одним хостом.Должно быть больше нуля.
      максимальное количество подключений = 4
  
      # Минимальное количество параллельных подключений, которые пул должен поддерживать ("горячие").
      # Если количество подключений падает ниже заданного порога, создаются новые.
      # Вы можете использовать этот параметр для создания горячего пула «всегда активных» подключений.
      # По умолчанию 0, что означает отсутствие активного соединения в данный момент.
      # Имейте в виду, что `min-connections` должно быть меньше, чем `max-connections` или равно
      мин-соединений = 0
  
      # Максимальное количество повторных попыток неудачных запросов,
      # (если запрос можно безопасно повторить), прежде чем сдаться и вернуть ошибку.# Установите в ноль, чтобы полностью отключить повторные запросы.
      максимальное количество попыток = 5
  
      # Максимальное количество открытых запросов, принятых в пул по всем
      # материализации любого из своих клиентских потоков.
      # Защищает от (случайной) перегрузки одного пула слишком большим количеством материализаций потока клиентов.
      # Обратите внимание, что при N одновременных материализациях максимальное количество открытых запросов в пуле
      # никогда не превысит N * max-connections * pipelining-limit.
      # Должна быть степенью 2 и > 0!
      максимальное количество открытых запросов = 32
  
      # Максимальная продолжительность соединения, которое будет поддерживаться в рабочем состоянии
      # Это количество изменяется на 10-процентную нечеткость, чтобы избежать одновременных переподключений.
      # по умолчанию "бесконечно"
      # Обратите внимание, что это реализовано только в новом пуле соединений хоста.
      максимальное время жизни соединения = бесконечное
  
      # Конвейерная обработка на стороне клиента в настоящее время не поддерживается.См. https://github.com/akka/akka-http/issues/32.
      предел конвейерной обработки = 1
  
      # Минимальная продолжительность задержки новых попыток подключения после неудачной предыдущей попытки подключения.
      #
      # Пул использует экспоненциальную рандомизированную схему отсрочки. После первой неудачи следующая попытка будет
      # попытка после случайного промежутка времени между отставкой базового соединения и удвоенной отсрочкой базового соединения. Если это
      # попытка также не удалась, следующая попытка будет задержана на удвоенную величину.Общая задержка ограничена с помощью
      # параметр `max-connection-backoff`.
      #
      # Отсрочка применяется ко всему пулу. т.е. после одной неудачной попытки подключения последующие попытки подключения
      # к этому хосту будет отложена для всех подключений пула. После восстановления сервиса соединения будут выходить
      # отсрочки один за другим из-за случайного дополнительного времени отсрочки. Это делается для того, чтобы избежать перегрузки только что восстановленного
      # сервисы с новыми подключениями ("гремящее стадо").
      #
      # Пример: base-connection-backoff = 100 мс, max-connection-backoff = 10 секунд
      # - После 1-го сбоя откат составляет от 100 до 200 мс.
      # - После 2-го, между 200 мс и 400 мс
      # - После 3-го, между 200 мс и 400 мс
      # - После 4-го, между 400 мс и 800 мс
      # - После 5-го, между 800 мс и 1600 мс
      # - После 6-го, между 1600 мс и 3200 мс
      # - После 7-го, между 3200 мс и 6400 мс
      # - После 8-го, между 5000 мс и 10 секундами (максимальное значение ограничено максимальным отставанием соединения, минимальное - половиной этого значения)
      # - После 9-го и т. д., остается между 5000 мс и 10 секундами
      #
      # Этот параметр применяется только к новой реализации пула и игнорируется для старой.
      отсрочка базового соединения = 100 мс
  
      # Максимальная продолжительность задержки между неудачными попытками подключения. Для получения дополнительной информации см. комментарий выше для
      # параметр `base-connection-backoff`.
      #
      # Этот параметр применяется только к новой реализации пула и игнорируется для старой.
      максимальное отставание соединения = 2 мин.
  
      # Время, по истечении которого пул незанятых соединений (без отложенных запросов)
      # автоматически завершится.Установите на «бесконечность», чтобы полностью отключить тайм-ауты простоя.
      тайм-аут простоя = 30 с
  
      # HTTP-соединения обычно используются для нескольких запросов, то есть они сохраняются между запросами. То
      # Параметр `akka.http.host-connection-pool.keep-alive-timeout` определяет, как долго пул поддерживает соединение между
      # запросы, прежде чем он закроет соединение (и в конечном итоге восстановит его).
      #
      # Обычный сценарий, в котором этот параметр полезен, — предотвращение состояния гонки, присущего HTTP: в большинстве случаев сервер
      # или обратный прокси-сервер закрывает постоянное (поддерживаемое) соединение через некоторое время.HTTP не определяет протокол между
      # клиент и сервер для согласования постепенного разрыва бездействующего постоянного соединения. Поэтому может случиться так, что сервер решит
      # закрыть соединение в то же время, когда клиент решает отправить новый запрос. В этом случае запрос не будет обработан,
      # но клиент не может определить по какой причине сервер закрыл соединение и был ли запрос (частично) обработан или нет.
      # Такое состояние можно наблюдать, когда запрос завершается с ошибкой `UnexpectedConnectionClosureException` или `StreamTcpException`
      # "Соединение сброшено узлом".#
      # Чтобы этого не произошло, вы можете установить тайм-аут на меньшее значение, чем тайм-аут проверки активности на стороне сервера.
      # (что либо нужно знать, либо выяснить экспериментальным путем).
      #
      # Установите значение `infinite`, чтобы позволить соединению оставаться открытым неограниченное время (или быть закрытым из-за более общего `idle-timeout`).
      тайм-аут поддержания активности = бесконечный
  
      # Реализация пула вызовет сбой соединения раньше и очистит слот, если объект ответа не был
      # подписались в течение заданного периода времени после отправки ответа.В занятых системах время ожидания может быть
      # слишком плотно, если ответ не получен достаточно быстро после того, как он был отправлен пулом.
      тайм-аут подписки-сущности-ответа = 1 секунда
  
      # Измените этот раздел, чтобы настроить параметры клиента только для API-интерфейсов пулов соединений хоста, таких как `Http().superPool` или
      # `Http().singleRequest`.
      клиент = {
        # по умолчанию никаких переопределений, смотрите `akka.http.client` для значений по умолчанию
      }
  
      #на-хост-переопределения
      # Позволяет переопределять настройки для каждого хоста. Настройка должна быть списком, в котором каждая запись
      # это объект с записью `host-pattern`, которая указывает, для каких хостов переопределяются
      # должно вступить в силу.Все остальные записи имеют тот же синтаксис, что и записи в
      # раздел `host-connection-pool`.
      #
      # `host-pattern` может иметь следующие формы:
      # * `regex:<шаблон>`: имя хоста сопоставляется с шаблоном регулярного выражения
      # * `glob:<шаблон-шаблона>` или просто `<шаблон-шаблона>`: хост сопоставляется с заданным
      #    шаблон. В шаблоне подстановочный знак `*` означает ноль или более символов, а `?`
      # для любого одиночного символа
      #
      # В обоих случаях шаблон, соответствующий `*.` в начале, т.е. каждый поддомен,
      # расширяется, чтобы также покрыть сам домен (без ведущей точки).
      #
      # Если шаблоны из нескольких записей в списке совпадают, только настройки из
      # применяется первая найденная запись.
      #
      # Пример:
      #
      # на хост-переопределение = [
      # {
      # host-pattern = "doc.akka.io"
      # # Используйте те же записи, что и в разделе `host-connection-pool`
      # максимальное количество подключений = 10
      # },
      # {
      # # `*.akka.io` соответствует всем субдоменам, таким как `repo.akka.io», но и сам akka.io.
      # # `doc.akka.io` уже охвачен предыдущей записью, так что эти настройки здесь
      # # не будет применяться к `doc.akka.io`.
      # host-pattern = "*.akka.io"
      # максимальное количество подключений = 11
      # }
      # ]
      переопределение для каждого хоста = []
      #на-хост-переопределения
  
    }
    #pool-настройки
  
    # Изменить, чтобы настроить параметры синтаксического анализа по умолчанию.
    #
    # ВАЖНЫЙ:
    # Обратите внимание, что настройки этого раздела могут быть переопределены соответствующими настройками в:
    # `akka.http.сервер.синтаксический анализ», «akka.http.client.parsing» или «akka.http.host-connection-pool.client.parsing».
    разбор {
      # Ограничения для различных частей парсера HTTP-сообщений.
      максимальная длина uri = 2k
      максимальная длина метода = 16
      максимальная длина причины ответа = 64
      максимальная длина имени заголовка = 64
      максимальная длина значения заголовка = 8k
      максимальное количество заголовков = 64
      максимальная длина фрагмента = 256
      максимальный размер блока = 1 м
  
      # HTTP-комментарии (например, часто используемые в заголовках User-Agent) могут быть вложенными.Чтобы избежать слишком глубокой вложенности
      # и связанных с этим затрат на синтаксический анализ и хранение, глубина вложенных комментариев ограничена заданным значением.
      максимальная глубина разбора комментариев = 5
  
      # Максимальное количество байтов, допустимое при чтении всего объекта в память с помощью `toStrict`
      # (используется директивами `toStrictEntity` и `extractStrictEntity`)
      max-to-strict-bytes = 8m
  
      # Устанавливает режим строгости для разбора целевых URI запроса.
      # Определены следующие значения:
      #
      # `strict`: требуются URI, соответствующие RFC3986,
      # при нарушениях срабатывает ответ 400
      #
      # `расслабленный`: разрешены все видимые 7-битные символы ASCII
      #
      uri-parsing-mode = строгий
  
      # Устанавливает режим разбора файлов cookie.# Определены следующие значения:
      #
      # `rfc6265`: анализируются только файлы cookie, соответствующие RFC6265. Окружающие двойные кавычки принимаются и
      # автоматически удаляется. Несоответствующие файлы cookie автоматически удаляются.
      # `raw`: Необработанный разбор допускает любой неуправляющий символ, кроме ';' отображаться в значении cookie. Дальше нет
      # применена постобработка, так что результирующая строка значения может содержать любое количество пробелов, юникод,
      # двойные кавычки или символы '=' в любой позиции.# Правила разбора имени куки такие же, как в RFC 6265.
      #
      режим разбора файлов cookie = rfc6265
  
      # Включает/отключает регистрацию предупреждающих сообщений в случае входящего
      # сообщение (запрос или ответ) содержит заголовок HTTP, который не может быть
      # анализируется в класс модели высокого уровня из-за несовместимого синтаксиса.
      # Обратите внимание, что независимо от этих настроек akka-http будет принимать сообщения
      # с такими заголовками до тех пор, пока сообщение в целом будет законным
      # по спецификации HTTP даже без этого заголовка.# Если заголовок не может быть проанализирован в высокоуровневый экземпляр модели, он будет
      # предоставляется как `RawHeader`.
      # Если ведение журнала включено, оно выполняется с настроенным
      # `ошибка-регистрация-многословие`.
      предупреждения о незаконных заголовках = вкл.
  
      # Устанавливает список заголовков, для которых недопустимые значения *не* будут вызывать генерацию журналов предупреждений;
      #
      # Добавление имени заголовка в этот список настроек отключает регистрацию предупреждающих сообщений в случае, если входящее　сообщение
      # содержит HTTP-заголовок, который нельзя разобрать на высокоуровневый класс модели из-за несовместимого синтаксиса.игнорировать-незаконный-заголовок-для = []
  
      # Разобрать заголовки в классы типизированной модели на основном уровне Akka Http.
      #
      # Если установлено значение `off`, только основные заголовки будут анализироваться в их классах моделей. Все остальные будут предоставлены
      # как экземпляры `RawHeader`. В настоящее время заголовки `Connection`, `Host` и `Expect` по-прежнему будут предоставляться в их
      # типизированная модель. Полный список заголовков, по-прежнему представленных в виде смоделированных экземпляров, можно найти в исходном коде
      # `akka.http.impl.engine.parsing.HttpHeaderParser.alwaysParsedHeaders`. Обратите внимание, что (независимо от этого параметра)
      # некоторые заголовки, такие как `Content-Type`, обрабатываются особым образом и никогда не будут представлены в списке заголовков.
      анализ смоделированного заголовка = вкл.
  
      # Настраивает детализацию, с которой анализируется сообщение (запрос или ответ).
      # ошибки записываются в журнал приложения.
      #
      # Поддерживаемые настройки:
      # `off`: сообщения журнала не создаются
      # `simple`: регистрируется сжатое однострочное сообщение
      # `full` : регистрируются полные сведения об ошибке (возможно, занимающие несколько строк).
      подробность регистрации ошибок = полная
  
      # Настраивает режим обработки при обнаружении недопустимых символов в
      # имя заголовка ответа.#
      # Поддерживаемый режим:
      # `error` : режим по умолчанию, отклонить запрос
      # `warn`: игнорировать недопустимые символы в значении заголовка ответа и записывать предупреждающее сообщение
      # `ignore`: просто игнорируйте недопустимые символы в значении заголовка ответа
      незаконный-ответ-заголовок-имя-режим обработки = ошибка
  
      # Настраивает режим обработки при обнаружении недопустимых символов в
      # значение заголовка ответа.
      #
      # Поддерживаемый режим:
      # `error` : режим по умолчанию, генерировать ParsingException и завершать обработку
      # `warn`: игнорировать недопустимые символы в значении заголовка ответа и записывать предупреждающее сообщение
      # `ignore`: просто игнорируйте недопустимые символы в значении заголовка ответа
      незаконный-ответ-заголовок-значение-режим обработки = ошибка
  
      # Настраивает режим обработки при обнаружении конфликтующих заголовков `Content-Type`.#
      # Поддерживаемый режим:
      # `error` : режим по умолчанию, генерировать ParsingException и завершать обработку
      # `first` : использовать значение первого заголовка `Content-Type` и добавить все последующие заголовки `Content-Type` в список заголовков
      # `last` : использовать значение последнего заголовка `Content-Type` и добавить все предыдущие заголовки `Content-Type` в список заголовков
      # `no-content-type`: используйте `ContentTypes.NoContentType` и добавьте все заголовки `Content-Type` в список заголовков
      режим обработки заголовков конфликтующего типа контента = ошибка
  
      # ограничения на количество различных значений для каждого типа заголовка, которые
      # кеш заголовков будет храниться
      заголовочный кеш {
        по умолчанию = 12
        Контент-MD5 = 0
        Дата = 0
        Если-совпадение = 0
        Если-Изменено-С = 0
        Если-Нет-совпадения = 0
        Если-диапазон = 0
        Если-Немодифицированный-С = 0
        Пользовательский агент = 32
      }
  
      # Включает/отключает включение заголовка Tls-Session-Info в анализируемый
      # сообщения через транспорты Tls (т.д., HttpRequest на стороне сервера и
      # HttpResponse на стороне клиента).
      tls-сессия-информация-заголовок = выкл.
  
      # Включает/отключает включение атрибута SslSession в анализируемый
      # сообщения через транспорты Tls (например, HttpRequest на стороне сервера и
      # HttpResponse на стороне клиента).
      SSL-сеанс-атрибут = выкл.
    }
  
  }  

  Предотвращение перебоев в работе сети из-за бесконечных проблем с потоковой передачей

  Если общее количество невыполненных действий ICAP для текущего сервера достигло порога отсрочки, устройство ProxySG откладывает самое старое соединение ICAP, которое еще не получило полный объект.

  Порог отсрочки задается администратором в процентах. Например, если порог отсрочки установлен на 70 процентов, а максимальное количество подключений установлено на 100, то разрешено до 70 подключений, прежде чем устройство ProxySG начнет откладывать подключение, которое не завершило загрузку полного объекта.

  См. Создание службы ICAP для получения информации об установке порогового значения отсрочки сканирования в консоли управления устройством ProxySG.

  Когда соединение ICAP отложено, соединение с сервером ICAP закрывается.Ответ приложения продолжает поступать, и когда загрузка завершена, запрос ICAP перезапускается. Новый запрос ICAP может по-прежнему стоять в очереди, если нет доступных соединений ICAP. После того, как запрос

  отложен, ICAP ожидает получения полного объекта перед перезапуском запроса. Если есть очередь, когда отложенное действие получило полный объект, это действие ставится в очередь после других отложенных действий, которые завершились. Однако он будет поставлен в очередь перед другими новыми запросами.

  Отложенное сканирование и настройка параметров обратной связи

  В зависимости от того, как вы настроите параметр обратной связи ICAP (страница терпения или передача данных) и размера объекта, отложенное сканирование может привести к задержке ответа ICAP, поскольку весь ответ должен быть отправлен на сервер ICAP сразу. Параметр обратной связи позволяет вам указать тип обратной связи, которую вы хотите получить во время сканирования ICAP. Сведения о настройке параметров обратной связи см. в разделе Настройка обратной связи ICAP.

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

  Если настроены параметры передачи данных, объект продолжает передаваться во время отложенного сканирования. Однако из-за требований к непрерывному буферу может возникнуть задержка с отложенным сканированием или без него, прежде чем устройство ProxySG начнет отправлять ответ.

  Об отказоустойчивости сервера ICAP

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

  Первичный сервер возобновляет обработку ICAP после успешной следующей проверки работоспособности; резервный сервер или группа серверов не несет основной ответственности.