Ниже — набор практических методов и команд, которые помогут диагностировать проблемы с приёмом/отдачей HTTPS между серверами (в дополнение к tracert/pathping и проверке сертификатов). Разделён по уровням — от простых HTTP‑проверок до низкоуровневых сетевых трассировок и пассивного/активного снятия трафика.
1) Быстрые HTTP/TLS проверки (простейшие и информативные)
- curl (показывает TLS handshake, redirection, код ответа):
- curl -v --resolve example.com:443:IP https://example.com/путь
- curl -v -I https://example.com
- curl -4/--ipv6 для проверки IPv4/IPv6
Что смотреть: успешный TLS handshake, Server certificate, HTTP статус, заголовки Connection/Keep‑Alive, редиректы, задержки и ошибки.
- openssl s_client (запуск TLS handshake, посмотреть сертификат, SNI, версии/шифры):
- openssl s_client -connect example.com:443 -servername example.com -showcerts
- openssl s_client -connect example.com:443 -tls1_2
Что смотреть: ServerHello, протокол/шифр, полная цепочка сертификатов, сообщения об ошибках (handshake failures, no shared cipher и т. п.).
- nmap (проверить порты/шифры):
- nmap -p 443 --script ssl-enum-ciphers example.com
2) Логирование и серверные логи
- Включить подробные логи на веб‑сервере (nginx/apache/IIS) и посмотреть входящие запросы/ответы, коды ошибок, таймауты, connection resets.
- В 1C: включить журнал входящих веб‑сервисов/HTTP‑обработок, если доступно.
- На стороне Bitrix/Connector — увеличить verbosity логов модуля, посмотреть ошибки повторных попыток и коды ответов.
3) Снятие трафика (tcpdump / tshark / Wireshark)
- Захватить трафик на обоих концах одновременно (если возможно) и сравнить:
- tcpdump -i eth0 host <IP_другого_сервера> and port 443 -w /tmp/cap.pcap
- tshark -i eth0 -f "host <IP> and port 443" -w cap.pcap
- Что искать в pcap:
- пара SYN→SYN/ACK→ACK (есть ли TCP handshake);
- много повторных SYN (потеря/фильтрация SYN);
- RST/FIN — кто их посылает и почему;
- TCP Retransmissions, Out‑of‑order, long gaps (пакеты уходят, но нет ответов);
- TLS ClientHello / ServerHello (если TLS не шифруется приватно — видны только TLS records; нельзя декодировать без ключа).
- Если можете получить приватный ключ сервера/ключ сессий — можно разгадать TLS в Wireshark (или настроить SSLKEYLOGFILE на клиенте).
4) Диагностика TCP/MTU/ICMP (Path MTU blackhole)
- Проверка PMTU/fragmentation:
- ping -M do -s <size> <IP> (на Linux) — тестировать, уменьшая MTU; если большие пакеты теряются, возможно PMTU block.
- tcpdump + анализ ICMP "fragmentation needed" сообщения.
5) Интермедиатные устройства (firewall, NAT, IDS/IPS, WAF, прокси, балансировщики)
- Убедиться, что между серверами нет прозрачного прокси/SSL‑терминирующего устройства. Сравнить fingerprint сертификата (openssl s_client) с тем, что ожидаете — если сертификат инжектится, то есть MITM.
- Проверить правила firewall (iptables, nftables, edge‑firewall) — возможны rate‑limits, connection tracking overflow:
- sudo ss -s (статистика сокетов)
- sudo ss -tanp | grep <port>
- cat /proc/sys/net/netfilter/nf_conntrack_max (и смотреть текущие conntrack: conntrack -L)
- На балансировщиках/NGINX/HAProxy — смотреть на таймауты keepalive, лимиты соединений и healthcheck.
6) Проблемы с DNS и IPv6
- Иногда запросы чередуются между IPv4 и IPv6 IP и одна из сетей некорректна:
- dig +short example.com A/AAAA
- curl -4 / curl -6 тесты
- TTL, разные ответы от DNS серверов (время от времени).
7) Поведение Keep‑alive и долгих соединений
- Некоторые межсетевые устройства разрывают долгие TCP‑соединения. Проверить:
- повторные последовательные запросы по одному соединению (curl с --keepalive) и смотреть кто обрывает.
- на сервере — настройки keepalive timeout (nginx proxy_read_timeout, keepalive_timeout и т.д.).
8) Инспекция на прикладном уровне (HTTP)
- Использовать ngrep/httping/httpstat для мониторинга ответов HTTP.
- Запустить нагрузочное средство для воспроизведения: h2load/ab/siege/httperf — посмотреть, при какой нагрузке/времени возникают ошибки.
9) Активные TCP‑тесты
- hping3 для проверки SYN/ACK и флага:
- hping3 -S -p 443 example.com -c 5
- tcptraceroute для маршрута TCP (показывает где режут TCP пакет):
- tcptraceroute example.com 443
10) Проверить TLS‑особенности
- SNI — сервер может отдавать другой vhost, если SNI не прислан:
- openssl s_client -connect ip:443 -servername example.com
- ALPN/HTTP2 — если сервер требует http/2/ALPN, старый клиент может сбоить. Пробуйте с опцией curl --http1.1 или --http2.
- Проверить OCSP/CRL/OCSP stapling — если клиент блокирует на ожидании OCSP.
11) Системные ограничения и ресурсы
- Ephemeral ports exhaustion, ulimit, max open files, TCP backlog:
- ss -s, netstat -s, /proc/net/sockstat
- dmesg на предмет dropped connections
- Проверьте время сервера (разница времени может ломать клиента, токены, сертификат проверки CRL). timedatectl/status NTP.
12) Как собрать воспроизводимые данные/что запросить у клиента хоста Б24 и у 1С
- Пакетные дампы (pcap) с обеих сторон в момент сбоев.
- Логи веб‑сервера (access + error) с timestamp + идентификатором запроса.
- Curl/openssl вывод попыток в момент сбоя.
- Статистика conntrack и любые firewall logs (drop rules).
- Информация о NAT/балансировщике/прокси между узлами.
Короткий план действий, который обычно даёт результат:
1. curl/openssl s_client с обеих сторон, сравнить сертификаты и код ответа.
2. Параллельные tcpdump на обеих сторонах на период воспроизведения — собрать pcap.
3. Проанализировать pcap: есть ли TCP handshake; кто посылает RST/FIN; TLS handshake начинается или прерывается; много ретрансмиссией.
4. Проверить firewall/conntrack, NAT timeouts, балансировщики и правила rate limiting.
5. Проверить IPv4/IPv6 и DNS поведение.
6. Если TLS зашифрован и нужен полный разбор — получить server private key или ключи сессий (если можно) для расшифровки пcap, либо логировать и анализировать приложение на более высоком уровне.
Если хотите, пришлите:
- pcap (зашифрованные части нормальны) и вывод openssl s_client/curl из момента сбоя, а также журналы nginx/IIS/1C за тот же период — могу помочь проанализировать (указывайте timestamps и IP/порт).
Готов помочь с разбором конкретных tcpdump/логов — пришлите примеры.