Я запускаю несколько хостов в сети A, которые отправляют запросы к серверам (которые мне не принадлежат) в сети B, где-то в Интернете. К сожалению, многие из этих запросов оказываются поврежденными. Если я выполняю запросы по незашифрованному протоколу HTTP, я получаю странные ошибки, указывающие на поврежденный запрос. Если я делаю запросы по HTTPS, я получаю ошибки уровня SSL. Я могу воспроизвести проблему, запустив:
sh -e -c 'while true; do curl $SERVER > /dev/null; sleep 1; done'
Обычно в течение 20 запросов curl завершается с ошибкой типа «Неизвестная ошибка протокола SSL» или «Ошибка расшифровки предупреждений tlsv1». Я могу воспроизвести это на нескольких хостах в сети A, получая доступ к нескольким серверам в сети B. Но я не могу воспроизвести из сети A на другие серверы или с других хостов на сеть B. В этих случаях цикл выполняется бесконечно без ошибок.
Таким образом, совершенно очевидно, что мой TCP-поток между A и B поврежден. Это, кстати, продолжается уже более 3 дней.
Первый вопрос: как такое может случиться? TCP имеет контрольные суммы на уровне пакетов, и поврежденные пакеты, прошедшие контрольную сумму, должны быть намного реже, чем я вижу. Кроме того, если я запускаю сетевой захват, я не вижу много повторных передач (согласно фильтру wirehark tcp.analysis.retransmit), чего можно было бы ожидать, если бы пакеты были повреждены и не соответствовали контрольной сумме TCP. Я предполагаю, что какой-то маршрутизатор должен обрабатывать данные более высокого уровня (NAT? Прозрачный прокси?) И повредить данные, но исправить контрольную сумму?
Второй вопрос: есть ли какие-нибудь инструменты, которые я могу использовать для локализации проблемы? Я ничего не могу найти. Если бы я знал топологию сети и мог бы найти серверы HTTPS за каждым переходом между A и B, я мог бы запустить свой тест на них. Но я этого не делаю. Какой еще тест выявит повреждение сети?
Я связался с владельцами сети A и сети B, но пока они мне не помогли.
Обновление: всем, кто предлагает, какое устройство с ошибками может быть на пути, есть ли способ обнаружить это, кроме как связаться с владельцем?
Прежде всего, было бы полезно посмотреть, можете ли вы воспроизвести повреждение данных с помощью команды ping, а не TCP. Ping использует эхо-запрос ICMP, отправляет известную полезную нагрузку (которую вы даже можете указать, если вам нужно) и сообщит, если полезная нагрузка повреждена при возврате. По крайней мере, это то, что страница руководства говорит мне.
Вы, вероятно, захотите использовать большой размер пакета (возможно, 1400 байтов или около того) и посмотрите, можете ли вы указать низкий интервал, возможно, 0,1 секунды, чтобы вы могли воспроизвести ошибку за разумное время. Эти настройки будут генерировать примерно 15 кБ / с трафика к серверу и от него. (1400 байт / 0,1 секунды + служебные данные)
Так зачем использовать пинг вместо TCP-соединения? Потому что вы, вероятно, можете пинговать большинство хостов на пути между сервером и вашим клиентом, и поэтому вы можете проверить только часть пути.
Начнем с тестирования полного пути (вплоть до вашего сервера, чтобы определить, воспроизводит ли тест вашу проблему). Вооружившись traceroute, вы можете протестировать только часть пути. Каждый проведенный вами тест может разделить пространство поиска пополам, и после нескольких тестов вы сможете найти прыжок, вызывающий ваши проблемы.
Предостережение: это не будет работать так, как вы ожидаете, если повреждение происходит на обратном пути к тестовой машине, а не на прямом пути. Traceroute может только сказать вам, по какому маршруту идут ваши пакеты к сервер, а не путь, по которому будут возвращаться пакеты, и эти пути обязательно не совпадают. Тем не менее, этого должно быть достаточно, чтобы добраться куда-нибудь.
Удачи!
Кто-нибудь в очереди использует ускорители LAN / WAN? Эти аппаратные средства иногда выходят из строя, и их необходимо перезапускать, что может быть источником повреждения, а также проблем с производительностью.
Могут ли быть ложные IDS / IPS / прокси в любой сети, которая искажает пакеты только в / из другой сети? Это объяснило бы, почему он не воспроизводится с разных хостов.