Будни техподдержки: таинственная жёлтая лента на экране

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

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

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

Запрос

В службу поддержки обратился клиент. В его компании используют CRM-систему Bitrix24. Это инструмент для ведения бизнеса и отдельных проектов.

Одно из преимуществ портала и BitrixVM 7.2 — функция push-сервера, которая позволяет установить непрерывное соединение с сайтом, чтобы моментально получать уведомления и задачи без перезагрузки страницы.

Каждый раз при загрузке страницы веб-браузер соединяется с push-сервером и вверху страницы появляется жёлтая полоса с сообщением: «Устанавливаем соединение с сервером».

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

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

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

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

Причины возможны как со стороны сервера, так и со стороны клиента.

Начинаем разбираться

Составили список возможных причин возникновения проблемы со стороны сервера:

• В CMS Bitrix включены push-уведомления, а на стороне сервера эта функция не активирована.
• Со стороны сервера функция активирована, но настройки внутри CMS не согласованы с настройками сервера (часто такое происходит при переносе сайта).
• По системным причинам: push-сервер не работает или работает с нарушениями.
• Другие причины, не позволяющие работать push-серверу или нарушающие его доступность. Например, особые правила в брандмауэре сервера.

Составили список возможных причин возникновения проблемы со стороны клиента:

• Браузер не поддерживает push-уведомления.
• Провайдер блокирует трафик по необходимым портам.
• Брандмауэр компьютера блокирует исходящий трафик по необходимым портам.
• Настройки роутера блокируют постоянное активное соединение.

 

Ищем корень проблемы

Сначала решили проверить очевидные моменты. Проверили локализацию проблемы: она есть у всех сотрудников или только у кого-то отдельно. Оказалось, у всех. Открыли портал через другой браузер — никаких изменений не заметили.

Также мы сразу откинули версию о том, что проблема в качестве и скорости интернет соединения. У клиента стабильное подключение, отсутствуют разрывы и достаточная скорость .Мы пошли дальше.

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

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

Мы предположили, что в локальной сети клиента какой-то из роутеров, обеспечивающих доступ к интернету, лезет в пакеты HTTP-протокола и фильтрует их на основании каких-то политик безопасности.

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

Рано или поздно это всё равно следовало сделать, потому что работать со своим внутрикорпоративным порталом без шифрования трафика — не лучшая идея. Но клиент не хотел ничего менять до этого момента.

Для организации правильного SSL использовался бесплатный сертификат — Let's Encrypt, а также технический домен, прикреплённый для каждого из наших серверов. Например, для сервера с адресом 193.151.89.13 именем технического домена является 193-151-89-13.hostip.tucha.ua.

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

Откуда взялась проблема

Настройки роутера клиента блокировали постоянное активное соединение. Причина в том, что после перехода к нам, они заходили на сайт по 80-му порту.

Push-сервер требует периодически отправлять пакеты для сверки «А не пришло ли чего нового». Именно такие однообразные пакеты (keep-alive packets) отправлялись к веб-серверу.

Подключение по http-протоколу не защищено и открыто — любое промежуточное сетевое устройство может видеть данные, пересылаемые по 80-му порту.

Роутеру не нравилось, что между сервером и клиентом ходят однообразные пакеты (keep-alive). И, скорее всего, мешали политики доступа, о которых мы писали выше.

Соединение по https-протоколу шифруется — любое промежуточное сетевое устройство видит набор зашифрованных данных вместо однообразных пакетов. Следовательно, каким-либо образом фильтровать трафик уже не будет. Поэтому мы порекомендовали клиенту именно это решение проблемы.

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

Сейчас клиент доволен, а значит мы тоже.

Обращайтесь

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

И если у вас тоже есть ситуация, с которой вы не можете справиться самостоятельно, обращайтесь в нашу поддержку в любое время.