Pmonline.ru

Пром Онлайн
0 просмотров
Рейтинг статьи
1 звезда2 звезды3 звезды4 звезды5 звезд
Загрузка...

Битрикс настройка SSL, ошибка работы с сокетами

Битрикс настройка SSL, ошибка работы с сокетами

После установки SSL сертификата в битриксе на виртуальной машине BitrixVM версии 7.4.1 начала появляться ошибка с сокетами, при этом если перейти на сайт по обычному http, то такой проблемы не наблюдается.
Ниже описано как решить данную проблему с сокетами при использование SSL сертификата и протокола HTTPS в Bitrix virtual appliance version 7.4.1 («1С-Битрикс: Веб-окружение»).

Открываем SSH клиет (PuTTY).
Если меню битрикса не отображается сразу, то заходим в меню следующей командой:

Затем выбираем поочередно пункты в меню:

8. Manage pool web servers
3. Configure certificates
2. Configure own certificate

Если данных пунктов у вас нет, то сначала нужно обязательно создать пул:
1. Create Management pool of server

После того, как зашли в пункт 2. Configure own certificate, указываем сайт или оставляем по умолчанию Enter site name (default):

Указываем:
Private Key path: /etc/nginx/ssl/cert.key
Certificate path: /etc/nginx/ssl/cert.crt
Certificate Chain path: /etc/nginx/ssl/cert_ca.crt

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

После вопроса Please confirm you want to update certificate settings for the sites (N|y): вводим Y и нажимаем enter.

Готово, сайт должен открываться по HTTPS, но у меня не работало, поскольку я не указывал Certificate Chain path, у меня не было сертификатов для цепочки (промежуточных) и пока я не указал эти сертификаты в Certificate Chain path у меня SSL не работал. Точнее сам сайт по HTTPS открывался нормально в защищённом режиме, но в проверке системы битрикс показывалась ошибка с сокетами:
Ошибка! Работа с сокетами (check_socket): Fail Connection to ssl://site.com:443 Fail, Connection to ssl://site.com:443 Fail Socket error [0]:
Подробности ошибки указаны в журнале проверки системы.

Также если обратится к сайту в консоли через curl командой:
curl https:// site.com :443
выходило следующие curl: (60) Peer’s Certificate issuer is not recognized.
При нормальной работе должен показываться HTML код сайта.

Проблема еще была в том, что у меня не было никаких промежуточных сертификатов, а только публичный сертификат (CRT) и приватный ключ (Private KEY).

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

Как же их получить?
Нашёл решение такое, открываем сайт в браузере Firefox, нажимаем на замочек, затем на стрелку справа от зеленной надписи «Защищенное соединение», затем внизу «Подробнее».
После чего откроется окно «Информация о странице». Там нажимаем «Просмотреть сертификат».
Откроется страница с различными данными и параметрами сертификата. Находим ниже ссылки Загрузить PEM (сертификат) и PEM (цепочка сертификатов). Именно последний нам и нужен. Качаем PEM (цепочка сертификатов).

Формат PEM я переименовал в CRT. У меня сработало с ним, но возможно и с PEM сработает.
После того как я указал этот chain сертификат, как указано выше в Certificate Chain path, у меня наконец-то пропала ошибка с сокетами и все наконец стало работать как надо.

Записи о сертификатах создаются в файле:
/etc/nginx/bx/site_avaliable/ssl.s1.conf

там указано где хранятся сертификаты:
ssl_certificate /etc/nginx/certs/default/cert.crt;
ssl_certificate_key /etc/nginx/certs/default/cert.key;
ssl_trusted_certificate /etc/nginx/certs/default/cert_ca.crt;

Также данные записи были сделаны в файле /etc/nginx/bx/conf/ssl-push-custom.conf
А изначально настройки брались из /etc/nginx/bx/conf/ssl.conf

В документации вообще сказано, что для сайта по умолчанию s1 (который находится в директории /home/bitrix/www) файл будет называться /etc/nginx/bx/site_avaliable/s1.ssl.conf, а для дополнительных сайтов (которые создаются в директории /home/bitrix/ext_www/название_хоста) — /etc/nginx/bx/site_avaliable/bx_ext_ssl_название_хоста.conf.

Поэтому нужный файл конфигурации здесь еще нужно постараться определить.

Не забываем также указать в файле /etc/hosts ваш IP и домен. я указал два ip версии 4 и 6, а также 127.0.0.1 localhost

После правок нужно выполнить команду
nginx -t
И перезагрузить
service nginx restart или # /etc/init.d/nginx restart

Читайте так же:
Материнка для i5 7400

Если нужно установить бесплатный сертификат LetsEncrypt, об это написано в этой статье Установка SSL сертификата LetsEncrypt на BitrixVM

Ошибки SMTP-сервера и способы их решения

smtp error

SMTP-сервер — это программное обеспечение для отправки электронных писем, использующее SMTP протокол. Напомним, что вообще работа электронной почты обеспечивается с помощью трех протоколов: POP3 или IMAP — для получения писем, SMTP — для отправки.

Передача письма по SMTP происходит с помощью TCP-соединения. Стандартный порт для незащищенного соединения — 25. Однако многие сервисы по умолчанию его блокируют, так как именно на него обычно идет рассылка вирусного спама.

В качестве альтернативных можно прописывать в настройках порты 587 и 2525.

Для защищенного соединения по SSL используется порт 465.

Как работает SMTP-сервер

Функции почтового сервера SMTP сводятся к следующему:

    определить домен получателя письма и то, совпадает ли он с доменом отправителя;

определить IP-адрес сервера SMTP получателя;

установить соединение с ним;

с помощью серии запросов-ответов передать адреса отправителя и получателя, а также само письмо вместе с заголовками.

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

Виды почтовых серверов

SMTP-сервер встречается в нескольких вариантах:

  • Бесплатные серверы SMTP. Идут как дополнение к бесплатным почтовым сервисам, таким как Яндекс.Почта, Gmail, Mail.ru и другим. Предназначены в основном для личного использования и не подходят для корпоративных рассылок: есть ограничения на количество отправок, высокий риск попасть под спам-фильтры и т. д.
  • Сервер, предоставляемый интернет-провайдером. Этот вариант SMTP чем-то похож на использование бесплатных почтовых серверов: у вас также будут ограничения на отправку писем и, возможно, на скорость обработки очереди отправки
  • SMTP от хостинга. Обычно достаточно производительный и без ограничений на отправку. Но нужно учитывать, что при массовых рассылках и низком качестве списка получателей есть большой риск попасть под спам-фильтр, причем не только того адреса, с которого ведется рассылка, но и всего домена.
  • Коммерческие серверы SMTP. Предлагаются многими сервисами рассылок. Лучшее решение, если вы рассылаете множество писем, причем как транзакционных, так и рекламных. Обеспечивают быструю и надежную доставку и снижают риск попадания ваших писем в папку «Спам» у получателей.

Ответы SMTP-сервера. Коды успешной или неуспешной обработки запроса

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

  • 2xx. Такой ответ означает, что предыдущая команда была успешно выполнена.
  • 3xx. Коды, начинающиеся на тройку, высылаются на промежуточном этапе передачи, когда сервер ждет остальную часть данных.
  • 4xx. Это коды ошибок, которые могут носить временный характер.
  • 5xx. В эту категорию относятся коды критичных ошибок.

Коды ошибок SMTP, их причины и варианты исправления ситуации

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

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

Ошибка 421

Расшифровка ошибки SMTP 421 — «сервис недоступен». Причиной могут быть:

Блокировка трафика на 25 порту. Пропишите в настройках альтернативные порты.

Неправильно заданы настройки соединения. Проверьте и исправьте настройки.

Ваш антивирус или брандмауер блокирует соединение с сервером SMTP.

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

    Использование VPN. Встречается достаточно редко, но все же проверьте, отправляется ли письмо, если отключить VPN. Если да, то необходимо обратиться к администраторам VPN-сервиса, чтобы устранить проблему.
Читайте так же:
Материнская плата asrock h61m vg3

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

Грейслистинг (серый список). Это функция защиты от спама. Работает она следующим образом: в ответ на все подозрительные письма, письма с адресов, с которых сообщение приходит впервые, сервер отправляет эту ошибку. Если на стороне отправителя — легитимный SMTP-сервер, а не спамерское ПО, то через некоторое время он отправит письмо еще раз, и уже тогда сервер получателя примет письмо. Спамеры обычно не предпринимают повторных попыток отправки. Предпринимать в этом случае обычно ничего не нужно — если вы пользуетесь надежным сервером, он сам повторит отправку и письмо будет доставлено.

Ошибка 451

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

  • На DNS-сервере неправильно прописаны параметры почтового сервера (MX записи). Например, некорректно проставлены предпочтения, если почтовых серверов для домена несколько. Перепроверьте и исправьте записи. Возможно, потребуется также посмотреть логи и файлы конфигурации.
  • Превышены лимиты сервера на отправки или подключения. Проверьте, нет ли подозрительно большого количества отправляемых писем, если все нормально — увеличьте лимиты в настройках.

Ошибка 452

Означает, что либо у вас, либо у получателя закончилось место на машине, где установлен сервер, или не хватает памяти для обработки. Проверьте, есть ли в сообщении упоминание про «memory», и проверьте свою систему. Если у вас все в порядке, обратитесь к получателю.

Ошибка 550

Самый распространенный тип ошибки SMTP. В большинстве случаев возникает, если указан несуществующий email-адрес получателя. Но также возможны следующие причины:

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

Неправильно настроены параметры SMTP — перепроверьте настройки.

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

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

Ошибка 571

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

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

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

У вашего IP нет rDNS записи. Это необходимый параметр, без него ни один почтовый сервер не примет ваше письмо. Для решения проблемы обратитесь к хостинг-провайдеру.

Что делать, если сервер недоступен по сети

Рассмотрим случай, когда сервер доступен по VNC, но при этом не пингуется и не реагирует на попытки подключения по ssh. Тут есть несколько сценариев развития событий, о которых мы поговорим далее. Но сначала убедимся, что это наш случай, и проверим, есть ли пинг.

Проверка пинга

Запустить ping с вашего ПК до IP-адреса вашего сервера можно, например, через CMD : командная строка Windows ( Пуск — Все программы — Стандартные — Командная строка )

Если пинг проходит корректно, то вы увидите статистику переданных пакетов и время ответа, как на скриншоте:

В противном случае появится сообщение об ошибке, что говорит о сетевой недоступности, либо о проблемах с соединением:

Читайте так же:
Блок питания для маршрутизатора

Далее нужно зайти на сам сервер и проверить пинг с сервера до внешних ресурсов, перейдите в панель VMmanager и найдите в верхнем меню значок VNC .

Если вы используете VMmanager 6, то нажмите на кнопку VNC во вкладке Виртуальные машины .

В окне VNC необходимо авторизоваться и запустить ping до любого адреса, например 8.8.8.8 . Если сеть работает, то вы увидите количество переданных пакетов и время, за которое они достигли конечного адреса. Если нет, то придут сообщения вида network unreacheble, connection timeout, либо команда будет просто «висеть» без вывода.

Так как ping не проходит, это говорит о том, что не работает сеть. Поэтому переходим к следующему шагу и идём проверять, в чём может быть проблема.

Проверка сетевых настроек сервера

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

Диагностика проблем сети с помощью утилиты ip

Диагностировать проблему нам поможет утилита ip — она покажет имя, статус сетевого интерфейса и IP-адреса, которые ему назначены. Утилита установлена во всех современных linux-дистрибутивах.

На сервере с корректными настройками вывод будет таким:

В этом случае, нас интересует блок с названием нашего сетевого интерфейса — в этом случае eth0 (на разных ОС может называться по-разному, например, ens3, eno1).

Здесь прописан наш IP-адрес, маска и шлюз, что можно увидеть в строке:

На наших серверах используется технология VPU , поэтому в качестве сетевого шлюза на серверах используется адрес 10.0.0.1 , а маска подсети /32

Также следует обратить внимание на статус интерфейса. Если его статус DOWN, а не UP, то стоит попробовать запустить интерфейс вручную командой if up eth0 , где вместо eth0 укажите имя вашей сетевой карты. Ранее мы рассмотрели, где можно его найти.

На этом примере видно, что интерфейс не «поднимается» из-за синтаксических ошибок в конфигурационном файле сетевых настроек /etc/network/interfaces .

Также стоит проверить статус службы Network командой systemctl status networking . Если она не запущена, то стоит её запустить командой systemctl start networking . Если служба не запустилась, то, возможно, имеется ошибка в конфигурации, о чём будет сообщено в выводе команды запуска. Вам нужно обратить внимание на строку, которая начинается с Active . Обычно статус запуска службы выделен цветом: красным в случае ошибки и зелёным, если запуск был успешен — как на скриншотах ниже:

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

Должен быть прописан путь до 10.0.0.1 и он же установлен по умолчанию (дефолтным), как здесь:

Если сеть не заработала, проверяем пинг до шлюза 10.0.0.1 — если он проходит, возможно, проблемы на стороне хостинг-провайдера. Напишите нам в поддержку, разберёмся.

Проверка фаервола

Возможен вариант, что сеть настроена корректно, но трафик блокируется фаерволом внутри самого VDS.

Чтобы это проверить, первым делом смотрим на политики по умолчанию.
Для этого вводим iptables-save и смотрим на первые несколько строк вывода.

В начале мы увидим политику по умолчанию для соединений (цепочек) INPUT , OUTPUT , FORWARD — то есть правила для всех входящих, исходящих и маршрутизируемых соединений. Они имеют статус DROP либо ACCEPT .

Когда все соединения с сервера заблокированы, они имеют статус DROP , и вывод выглядит так:

Чтобы исключить влияние фаервола, просматриваем текущие правила с помощью iptables-save и сохраняем их в отдельный файл командой:

Меняем все политики по умолчанию на ACCEPT и сбрасываем все текущие правила командами:

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

Читайте так же:
Мощный ноутбук до 50000

Проверка влияния ПО

Возможен вариант, что установленные на сервере программы (особенно связанные с изменением маршрутизации на сервере, например, OpenVPN, Docker, PPTP) «ломают» работу сети. Чтобы исключить влияние установленного на сервер ПО, можно запустить сервер в режиме восстановления и проверить сеть.

Для этого в панели VMmanager останавливаем VDS и подключаем ISO-образ sysrescueCD через меню Диски :

В VMmanager 6 ISO-образ sysrescueCD подключается в Меню сервера по кнопке Режим восстановления на главной странице панели.

После загрузки образа подключаемся по VNC и выполняем команды (в VM6 еще потребуется сначала выбрать образ восстановления в VNC)

После чего запускаем пинг до 8.8.8.8 . Если он проходит, значит, с сетью на сервере всё благополучно.

Проверка на наличие сетевых потерь

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

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

Запускаем на сервере mtr до вашего IP, с которого пробуете подключаться, и с сервера — в обратном направлении до вашего адреса :

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

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

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

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

Какой правильный код ответа REST для действительного запроса, но пустых данных?

Например, вы выполняете запрос GET для, users/9 но нет пользователя с идентификатором # 9. Какой код ответа лучше?

  • 200 ОК
  • 202 Принято
  • 204 Нет содержимого
  • ошибка 400, неверный запрос
  • 404 Не Найдено

TL; DR: использовать 404

Смотрите этот блог . Это очень хорошо объясняет.

Сводка комментариев блога на 204 :

  1. 204 No Content не очень полезен в качестве кода ответа для браузера (хотя в соответствии со спецификацией HTTP браузеры должны понимать его как код ответа «не меняйте представление»).
  2. 204 No Content это , однако, очень полезно для AJAX веб — сервисов , которые могут хотеть , чтобы указать успех без необходимости что- то вернуть. (Особенно в таких случаях, как DELETE или POST с, которые не требуют обратной связи).

Поэтому ответом на ваш вопрос является использование 404 в вашем случае. 204 является специализированным кодом ответа, который вы не должны часто возвращать в браузер в ответ на GET .

Другие коды ответов, которые даже менее подходят, чем 204 и 404 :

  1. 200 должны быть возвращены с телом того, что вы успешно получили. Не подходит, когда сущность, которую вы выбираете, не существует.
  2. 202 используется, когда сервер начал работу с объектом, но объект еще не полностью готов. Конечно, дело не в этом. Вы не начали и не начнете создание пользователя 9 в ответ на GET запрос. Это нарушает все виды правил.
  3. 400 используется в ответ на плохо отформатированный HTTP-запрос (например, искаженные заголовки http, неправильно упорядоченные сегменты и т. д.). Это почти наверняка будет обработано любой платформой, которую вы используете. Вам не придется иметь дело с этим, если вы не пишете свой собственный сервер с нуля. Редактировать : более новые RFC теперь позволяют использовать 400 для семантически неверных запросов.
Читайте так же:
Материнская плата asus p5q se2 характеристики

Я категорически против 404 в пользу 204 или 200 с пустыми данными. Или, по крайней мере, следует использовать объект ответа с 404.

Запрос был получен и правильно обработан — он вызвал код приложения на сервере, поэтому нельзя сказать, что это была ошибка клиента, и поэтому весь класс кодов ошибок клиента (4xx) не подходит.

Что еще более важно, 404 может произойти по ряду технических причин. Например, приложение временно деактивировано или удалено на сервере, проблемы с подключением к прокси и так далее. Поэтому клиент не может различить 404, что означает «пустой набор результатов», и 404, что означает «служба не может быть найдена, повторите попытку позже».

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

-> Для приложений, которые заботятся о качестве своих данных, 404 без объекта ответа, таким образом, в значительной степени является запретом.

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

Преимущество 404 над 204 состоит в том, что он может возвращать объект ответа, который может содержать некоторую информацию о том, почему запрошенный ресурс не был найден. Но если это действительно актуально, то можно также рассмотреть возможность использования ответа «200 OK» и спроектировать систему таким образом, чтобы можно было реагировать на ошибки в данных полезной нагрузки. В качестве альтернативы можно использовать полезную нагрузку ответа 404 для возврата структурированной информации вызывающей стороне. Если он получает, например, html-страницу вместо XML или JSON, которую он может проанализировать, то это хороший индикатор того, что что-то техническое пошло не так, вместо ответа «нет результата», который может быть действительным с точки зрения вызывающего. Или для этого можно использовать заголовок ответа HTTP.

Тем не менее, я бы предпочел 204 или 200 с пустым ответом, хотя. Таким образом, статус технического выполнения запроса отделен от логического результата запроса. 2xx означает «техническое исполнение хорошо, это результат, разберитесь с ним».

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

Еще одна быстрая аналогия: возвращать 404 для «результат не найден» — это все равно, что выдавать исключение DatabaseConnectionException, если запрос SQL не дал результатов. Он может выполнить работу, но существует множество возможных технических причин, которые вызывают одно и то же исключение, которое затем будет ошибочно принято за действительный результат.

голоса
Рейтинг статьи
Ссылка на основную публикацию
Adblock
detector