Анализ несоответствия TLS SNI PCAP: неправильный сертификат, неправильный хост, прокси-маршрутизация и сбой установления связи

Несоответствие TLS SNI — частая причина сбоев HTTPS, API, MQTT, gRPC и WebSocket. Клиент подключается к правильному IP-адресу, но сервер возвращает неправильный сертификат. Браузер говорит, что сертификат предназначен для другого хоста. Прокси-сервер направляет запрос не на тот сервер. Приложение сообщает: "«Ошибка проверки сертификата», «Несоответствие имени хоста» или «Ошибка установления связи». Пользователи ищут «несоответствие TLS SNI pcap», «неправильный захват пакета сертификата», «ClientHello SNI Wireshark» и «несоответствие сертификата обратного прокси-сервера», поскольку DNS и TCP могут выглядеть правильно, пока TLS не работает."

PCAP Surgery полезен, поскольку решающее значение часто проявляется в TLS ClientHello и времени ответа сервера.

Что делает SNI

Индикация имени сервера позволяет клиенту TLS сообщить серверу, какое имя хоста ему нужно:

ClientHello
SNI: api.example.com

Common causes

SNI mismatch can happen when:

Packet evidence

In a pcap, preserve:

Proxy and upstream SNI

Reverse proxies can have two TLS legs:

• Client to proxy.
• Proxy to upstream.

Checklist

Use this workflow:

Final diagnosis

<!-- pcap-localized-evidence-foundation-v1:start -->

Пакетный ответ для «Анализ несоответствия TLS SNI PCAP: неправильный сертификат, неправильный хост, прокси-маршрутизация и сбой установления связи»

Краткий ответ: label анализатора или сообщение приложения не определяет причину. Начните с точки захвата и направления, докажите последнюю успешную protocol boundary и первую неудачную. Для «Анализ несоответствия TLS SNI PCAP: неправильный сертификат, неправильный хост, прокси-маршрутизация и сбой установления связи» другой reviewer должен найти packet, gap или interval, поддерживающий каждую фразу, и понять, какой факт её опровергнет.

Разместите capture на карте пути

Запишите client, server и все proxy, load balancer, NAT или firewall. Укажите interface, место, clock, OS и видимые направления. Capture у client доказывает приход туда, но не отсутствие отправки server. Capture у server доказывает выход в этой точке, но не весь путь. Перед сравнением двух точек исправьте clock offset и сопоставьте flow tuple, TCP sequence или transaction ID.

Проверьте snap length, dropped packets, offload, capture filter, ring buffer и время старта. Bad checksum на host может быть offload artifact. Большой segment может быть результатом GRO/TSO и не существовать так на проводе. Отсутствие packet в ограниченном файле не является network loss, пока не доказано, что точка обязана была его видеть.

Читайте границы по порядку

Граница	Успешный признак	Полезный признак отказа
Link/IP	direction, addresses и route согласованы	нет ARP/NDP, ICMP, MTU, asymmetry
TCP	SYN, SYN-ACK, ACK и sequence	retransmission, RST, zero window, timeout
TLS	ClientHello, ServerHello и прогресс	alert или SNI/ALPN/certificate boundary
Application	полный request и связанный response	status, gap или ранний close
User	response time или failure window	stall на доказанной границе

Остановитесь на первой границе без успеха. Если TCP не завершён, не начинайте с HTTP. Если request пришёл на proxy, но отсутствует на upstream, граница внутри proxy или его пути. Если upstream получил запрос без response до timeout, ACK и продвижение bytes отделяют application delay от network loss.

Отделите observation от hypothesis

Observation можно указать: «Client отправил до определённой sequence, sender повторил segment трижды, а в этой точке не появилось продвигающего ACK». Hypothesis: «путь потерял segment». Другая точка или dropped records могут её опровергнуть. Для каждой гипотезы запишите подтверждающий и опровергающий факт.

Retransmission и duplicate ACK не назначают виновного. Reordering, loss, capture artifact и receiver delay дают похожие labels. Свяжите direction, sequence, ACK, SACK, RTT, window и application timing. Для DNS/DHCP сопоставляйте transaction ID и attempts; для HTTP request/response; для TLS направление handshake.

Сохраните original

Рассчитайте checksum и не изменяйте оригинал. Filter, trim и redaction выполняются над working copy. Запишите input, operation, время, packet count до/после, output checksum и причину. После timestamp rewrite или удаления packets копия не поддерживает часть выводов о timing и sequence.

Addresses и identifiers заменяйте устойчивыми aliases. Не удаляйте port, direction и length, если они нужны выводу. Secret mapping держите отдельно. Проверьте границы capture и export и обзор PCAP Surgery.

QA перед публикацией

Title и answer относятся к одному flow? Каждая duration называет clock и точки? Первая failure boundary определена? Есть alternative explanation? Повтор меняет одну переменную? Original сохранён? Ограничьте итог: «Файл доказывает поведение около client в этом interval, но не внутреннее выполнение server».

Проверенный Semrush-термин PCAP analyzer принадлежит только странице продукта. Техническая статья не получает выдуманный volume или KD.

<!-- pcap-localized-evidence-foundation-v1:end --><!-- pcap-localized-flow-verdicts-v1:start -->

Flow ledger и исключающий тест

Для «Анализ несоответствия TLS SNI PCAP: неправильный сертификат, неправильный хост, прокси-маршрутизация и сбой установления связи» создайте строку по каждому направлению: endpoint aliases, первый/последний packet, отправленные и подтверждённые bytes, resets, retransmissions, requests и responses. Одинаковый hostname не объединяет соединения; source port, время старта и TCP initial sequence разделяют sessions. Для NAT/proxy запишите связь flows, не ожидая одинаковых sequence и ports.

Считайте TCP, а не labels

Следите за next expected sequence receiver. Payload сдвигает sequence на длину; SYN и FIN также занимают номер. Стабильный Duplicate ACK после более высоких segments поддерживает loss или reordering. SACK blocks показывают пришедшие ranges, но не место потери. Retransmission у sender без появления у receiver требует проверки пути; отсутствие original уже в sender capture требует проверки capture loss или offload.

Отделяйте fast retransmit после duplicate ACKs от RTO после тишины. Сравните предыдущий RTT, advertised window, zero-window probes, burst и размер transfer. Overlap, spurious retransmission и capture с середины flow меняют label, поэтому число labels не равно числу потерь.

Измеряйте время по границам

Используйте request first byte, request complete, response first byte и response complete. TTFB не равен server time автоматически. Retransmission до response может добавить network delay; полностью подтверждённый request и долгая тишина поддерживают application wait. Укажите значение, unit, clock и point.

Для двух точек совместите характерный packet в обоих направлениях, оцените offset и используйте intervals внутри файлов. При неизвестном clock дайте range. Сравнивайте успешные и неудачные windows одинаковой длительности и нагрузки.

Вопросы протокола

DNS: совпадают ID, name и type, меняет ли retry resolver/source port? DHCP: относятся ли Discover/Offer/Request/ACK к одному client identifier? TLS: последнее handshake message каждого направления и alert. HTTP: кто создал 4xx/5xx и есть ли upstream flow? TCP close: кто отправил FIN/RST и какие bytes не подтверждены?

Решающий тест и передача

Выберите две гипотезы и один разделяющий тест. Capture у другого конца разделяет network loss и measurement loss; выключение offload в тесте проверяет artifact; одинаковый request на фиксированном path — intermittency; upstream log против packet boundary — application delay. Запишите ожидания заранее.

Reviewer должен повторить расчёт по metadata, найти ту же границу и назвать ограничение. Передайте original/derived checksums, filter, packet ranges и операции trim/redaction. Закончите owner, действием и измеримым условием закрытия.

Проверка воспроизводимости

Откройте новую connection и повторите сценарий трижды с одинаковыми inputs и filters. Ports и initial sequence могут меняться, но boundary, direction и response pattern должны повторяться. Запишите успехи и отказы. Исправление меняет одну переменную; после него должно измениться ожидаемое packet behavior, а не только исчезнуть сообщение.

Откройте derived copy на другом компьютере. Reviewer находит flow aliases, clock, capture point, последний успех, первый отказ и alternative. После redaction снова ищите hostname, query, header и чувствительный payload, сохраняя нужные length и direction. Перечислите непроверенное: обратное направление, IPv6, reconnect, другая load.

Итог: доказано в указанном объёме, всё ещё воспроизводится или открыто из-за конкретного capture. Не пишите «сеть исправлена», если проверен один flow.

Противоположный контроль и доверие

До закрытия «{{TITLE}}» запишите противоположный прогноз. Если причина в network path, какой pattern должен быть виден в двух точках после переноса capture? Если это server delay, останутся ли request bytes подтверждёнными при отсутствии response? Ожидания до теста предотвращают подгонку объяснения после результата.

Свяжите confidence с доказательствами. High требует повторения и двух точек либо независимого подтверждения; medium — полного capture с непроверенной alternative; low — только label или примерного timing. Confidence не превращает hypothesis в fact, но задаёт next action.

Для медленного или intermittent failure измеряйте дольше обычного интервала. Сравнивайте rates: retransmissions на мегабайт, failures на connection и latency percentiles при сходной load. Запишите idle, reconnect, DNS cache и TLS session reuse, так как они меняют второй запуск.

Передайте flow table, timeline из пяти событий, first difference, exclusion test, fix result и untested scope. Packet numbers относятся к derived copy, а time map возвращает к original. Получатель должен повторить verdict без secrets и без session автора.

Журнал версий и приёмки

Original, working copy и report получают разные IDs. Manifest записывает размер, packet count, capture start/end, checksum, инструмент и version. Новый export создаёт новую версию и не заменяет предыдущую. Сохраните фактический filter: описание «только server traffic» не позволяет повторить выборку.

Свяжите каждый итоговый claim с packet или interval и пометьте observed, calculated или inferred. Observed — видимое field; calculated — повторяемый расчёт sequence или time; inferred — объяснение, которое ещё требует теста. При сокращении отчёта inferred не должно превращаться в observed.

Reviewer записывает имя, время, результат и открытые вопросы. После исправления новый run начинается из того же состояния, а evidence до и после сохраняется. Статус pass относится только к названным flow, direction, duration и load; всё остальное явно остаётся за пределами проверки.

Перед публикацией откройте rendered page и убедитесь, что таблица, headings и internal links видимы, а locale canonical указывает на собственный route. Проверка только исходного Markdown не доказывает качество публичного HTML.

Проверьте, что direct answer действительно отвечает title, таблица сохраняет оба направления, а internal link открывает ту же locale. Запишите дату и reviewer rendered-проверки. English fallback, пропавший section или неверный порядок headings необходимо исправить до submission. Повторите поиск чувствительных значений уже в публичном HTML, поскольку metadata и generated navigation могут вернуть текст, удалённый из body. Проверьте mobile и desktop viewport: таблица, code и предупреждение о capture point должны оставаться читаемыми. Если строка обрезается, исправьте layout без удаления технических полей. Выполните последний контроль canonical и links по generated page, записав status code, язык и destination. Отдельно проверьте JSON-LD на утечку удалённых значений. Запишите все redirects и убедитесь, что между source route и canonical нет цепочки или loop. Финальная проверка должна быть подписана, датирована и сохранена.

<!-- pcap-localized-flow-verdicts-v1:end -->