Новая сеть не использует обновленный TLS и не может подключиться к некоторым веб-сайтам.

У меня есть 2 сети, которые настроены почти идентично. У обеих один и тот же маршрутизатор – Mikrotik RB2011UiAS-RM, с прямым оптоволоконным подключением к интернет-провайдеру. Я использую одного и того же интернет-провайдера для обеих сетей. Моя первая сеть работает без значительных проблем уже около 4 лет. Новая сеть работает примерно 2 месяца. Я настроил вторую сеть по аналогии с первой, поэтому они настроены с теми же VLAN, IP-адресами и т.д. Все кажется, работает нормально, но последние пару недель мне начали поступать жалобы на то, что некоторые веб-сайты не загружаются.

Проблемы связаны с веб-сайтами, которые не загружаются, и, кажется, случайным образом, на каких именно сайтах возникает проблема. Например, Hulu.com загружается, но вход в Hulu не удается. Самая большая проблема в том, что некоторые сайты поставщиков компании не загружаются. На них я и сосредоточил своё внимание, поскольку они должны работать для компании.

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

2097    81.935154   10.0.100.193    45.60.196.32    TCP 66  50793 → 443 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 WS=256 SACK_PERM
2098    81.936384   10.0.100.193    45.60.196.32    TCP 66  50794 → 443 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 WS=256 SACK_PERM
2111    81.976423   45.60.196.32    10.0.100.193    TCP 66  443 → 50793 [SYN, ACK] Seq=0 Ack=1 Win=64240 Len=0 MSS=1460 SACK_PERM WS=128
2112    81.976513   45.60.196.32    10.0.100.193    TCP 66  443 → 50794 [SYN, ACK] Seq=0 Ack=1 Win=64240 Len=0 MSS=1460 SACK_PERM WS=128
2113    81.976549   10.0.100.193    45.60.196.32    TCP 54  50793 → 443 [ACK] Seq=1 Ack=1 Win=262656 Len=0
2114    81.976616   10.0.100.193    45.60.196.32    TCP 54  50794 → 443 [ACK] Seq=1 Ack=1 Win=262656 Len=0
2115    81.977504   10.0.100.193    45.60.196.32    TLSv1   571 Client Hello
2116    81.978230   10.0.100.193    45.60.196.32    TLSv1   571 Client Hello
2124    82.017575   45.60.196.32    10.0.100.193    TCP 60  443 → 50793 [ACK] Seq=1 Ack=518 Win=64128 Len=0
2125    82.017984   45.60.196.32    10.0.100.193    TCP 60  443 → 50794 [ACK] Seq=1 Ack=518 Win=64128 Len=0
2126    82.018045   45.60.196.32    10.0.100.193    SSL 1230    [TCP Previous segment not captured] , Continuation Data
2127    82.018081   10.0.100.193    45.60.196.32    TCP 66  [TCP Dup ACK 2113#1] 50793 → 443 [ACK] Seq=518 Ack=1 Win=262656 Len=0 SLE=2921 SRE=4097
2128    82.018447   45.60.196.32    10.0.100.193    SSL 1230    [TCP Previous segment not captured] , Continuation Data
2129    82.018491   10.0.100.193    45.60.196.32    TCP 66  [TCP Dup ACK 2114#1] 50794 → 443 [ACK] Seq=518 Ack=1 Win=262656 Len=0 SLE=2921 SRE=4097
2130    82.018816   45.60.196.32    10.0.100.193    SSL 236 [TCP Previous segment not captured] , Continuation Data
2131    82.018853   10.0.100.193    45.60.196.32    TCP 74  [TCP Dup ACK 2113#2] 50793 → 443 [ACK] Seq=518 Ack=1 Win=262656 Len=0 SLE=5557 SRE=5739 SLE=2921 SRE=4097
2132    82.019221   45.60.196.32    10.0.100.193    SSL 236 [TCP Previous segment not captured] , Continuation Data
2133    82.019246   10.0.100.193    45.60.196.32    TCP 74  [TCP Dup ACK 2114#2] 50794 → 443 [ACK] Seq=518 Ack=1 Win=262656 Len=0 SLE=5557 SRE=5739 SLE=2921 SRE=4097
2414    91.975313   45.60.196.32    10.0.100.193    TCP 60  443 → 50793 [FIN, ACK] Seq=5739 Ack=518 Win=64128 Len=0
2415    91.975378   10.0.100.193    45.60.196.32    TCP 74  [TCP Dup ACK 2113#3] 50793 → 443 [ACK] Seq=518 Ack=1 Win=262656 Len=0 SLE=5557 SRE=5739 SLE=2921 SRE=4097
2416    91.980004   45.60.196.32    10.0.100.193    TCP 60  443 → 50794 [FIN, ACK] Seq=5739 Ack=518 Win=64128 Len=0
2417    91.980052   10.0.100.193    45.60.196.32    TCP 74  [TCP Dup ACK 2114#3] 50794 → 443 [ACK] Seq=518 Ack=1 Win=262656 Len=0 SLE=5557 SRE=5739 SLE=2921 SRE=4097
3135    111.978393  10.0.100.193    45.60.196.32    TCP 54  50793 → 443 [FIN, ACK] Seq=518 Ack=1 Win=262656 Len=0
3136    111.978658  10.0.100.193    45.60.196.32    TCP 54  50794 → 443 [FIN, ACK] Seq=518 Ack=1 Win=262656 Len=0
3139    112.280923  10.0.100.193    45.60.196.32    TCP 54  [TCP Retransmission] 50794 → 443 [FIN, ACK] Seq=518 Ack=1 Win=262656 Len=0
3140    112.280923  10.0.100.193    45.60.196.32    TCP 54  [TCP Retransmission] 50793 → 443 [FIN, ACK] Seq=518 Ack=1 Win=262656 Len=0
3150    112.882128  10.0.100.193    45.60.196.32    TCP 54  [TCP Retransmission] 50793 → 443 [FIN, ACK] Seq=518 Ack=1 Win=262656 Len=0
3151    112.882127  10.0.100.193    45.60.196.32    TCP 54  [TCP Retransmission] 50794 → 443 [FIN, ACK] Seq=518 Ack=1 Win=262656 Len=0
3163    114.097284  10.0.100.193    45.60.196.32    TCP 54  [TCP Retransmission] 50794 → 443 [FIN, ACK] Seq=518 Ack=1 Win=262656 Len=0
3164    114.097284  10.0.100.193    45.60.196.32    TCP 54  [TCP Retransmission] 50793 → 443 [FIN, ACK] Seq=518 Ack=1 Win=262656 Len=0
3193    116.514004  10.0.100.193    45.60.196.32    TCP 54  [TCP Retransmission] 50794 → 443 [FIN, ACK] Seq=518 Ack=1 Win=262656 Len=0
3194    116.514004  10.0.100.193    45.60.196.32    TCP 54  [TCP Retransmission] 50793 → 443 [FIN, ACK] Seq=518 Ack=1 Win=262656 Len=0
3387    121.329207  10.0.100.193    45.60.196.32    TCP 54  [TCP Retransmission] 50794 → 443 [FIN, ACK] Seq=518 Ack=1 Win=262656 Len=0
3388    121.329207  10.0.100.193    45.60.196.32    TCP 54  [TCP Retransmission] 50793 → 443 [FIN, ACK] Seq=518 Ack=1 Win=262656 Len=0
3727    130.944445  10.0.100.193    45.60.196.32    TCP 54  50794 → 443 [RST, ACK] Seq=519 Ack=1 Win=0 Len=0
3728    130.944445  10.0.100.193    45.60.196.32    TCP 54  50793 → 443 [RST, ACK] Seq=519 Ack=1 Win=0 Len=0

Таким образом, когда я увидел это, я понял, что есть проблема с сервером, который не отвечает на TLS Client Hello, отправленный с моего компьютера. Это не стало понятно, пока я не сделал ещё одну запись в первой сети и не увидел, что происходит:

141 8.485975    10.0.100.193    45.60.196.32    TCP 66  49533 → 443 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 WS=256 SACK_PERM
143 8.495430    10.0.100.193    45.60.196.32    TCP 66  49534 → 443 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 WS=256 SACK_PERM
160 8.529277    45.60.196.32    10.0.100.193    TCP 66  443 → 49533 [SYN, ACK] Seq=0 Ack=1 Win=64240 Len=0 MSS=1340 SACK_PERM WS=128
161 8.529397    10.0.100.193    45.60.196.32    TCP 54  49533 → 443 [ACK] Seq=1 Ack=1 Win=262400 Len=0
162 8.530000    10.0.100.193    45.60.196.32    TLSv1.3 571 Client Hello
163 8.538789    45.60.196.32    10.0.100.193    TCP 66  443 → 49534 [SYN, ACK] Seq=0 Ack=1 Win=64240 Len=0 MSS=1340 SACK_PERM WS=128
164 8.538878    10.0.100.193    45.60.196.32    TCP 54  49534 → 443 [ACK] Seq=1 Ack=1 Win=262400 Len=0
165 8.539542    10.0.100.193    45.60.196.32    TLSv1.3 571 Client Hello
180 8.572428    45.60.196.32    10.0.100.193    TCP 60  443 → 49533 [ACK] Seq=1 Ack=518 Win=64128 Len=0
181 8.575808    45.60.196.32    10.0.100.193    TLSv1.3 1394    Server Hello, Change Cipher Spec, Application Data
182 8.575965    45.60.196.32    10.0.100.193    TCP 1394    443 → 49533 [PSH, ACK] Seq=1341 Ack=518 Win=64128 Len=1340 [TCP segment of a reassembled PDU]

По какой-то причине на моей новой сети мой компьютер не использует TLSv1.3, он использует TLSv1, и я подозреваю, что сервер не отвечает, потому что он не хочет использовать устаревший протокол. (Что мне кажется логичным.) Итак, я понимаю, что происходит, но я не могу понять, почему мой компьютер делает это.

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

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

Заранее спасибо за вашу помощь.

Обновление:
Я вернулся к новой сети, чтобы немного исследовать. Теперь я еще больше запутался. Я только что сделал запись только на своем IP-адресе и попытался выполнять обычную работу/просмотр веб-страниц и обнаружил много сайтов, которые не загружаются. Amazon работает нормально. ServerFault и StackOverflow не загружаются. Поэтому я отфильтровал свою запись по протоколу TLS и определенно вижу, что TLSv1.2 и TLSv1.3 успешно работают в этой сети, но, похоже, выборочно. Во всех случаях, когда сайт не загружается/переключается на тайм-аут, мой компьютер пытается общаться через TLSv1. Я просто не понимаю, почему он это делает, когда сайт поддерживает более высокий протокол.

Обновление #2:
2 новых события, которые произошли вчера:

1. Я проверил системное время на всех своих коммутаторах и своем маршрутизаторе. На маршрутизаторе было установлено правильное время, но мои коммутаторы все еще были на установках по умолчанию, примерно 2000 года. Поэтому я установил время для всего моего сетевого оборудования, но это не решило мою проблему.
2. Я выполнил трассировку на обоих местах и получил совершенно разные результаты. Новая сеть (та, что не подключается) имела 15 прыжков, в то время как другая сеть имела 9 прыжков. У меня один и тот же интернет-провайдер на обоих местах, и первые 2 прыжка после выхода из локальной сети были точно такими же, а затем для новой сети все начало усложняться. Я отправил это своему интернет-провайдеру и жду от них ответа.

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

Обновление #3:
Мой интернет-провайдер прислал техника с медиаконвертером, который подключил их ноутбук непосредственно к волоконной сети и все сайты работали просто превосходно. Так что что-то в моем маршрутизаторе вызывает проблему коммуникации. Кроме того, я даже понизил версию моего “нерабочего” маршрутизатора до той же версии, что и у сети без проблем. Проблема все еще остается. Стоит отметить, что мой интернет-провайдер настроил статический маршрут для одного из сайтов, на которых у нас возникают проблемы, и на этом сайте нет проблем. Поэтому я думаю, что маршрутизация пакетов тоже может играть роль. Я определил некоторые PPP настройки, с которыми могу попробовать поработать, но я не надеюсь, что они окажутся проблемой. В то же время я обратился к Mikrotik, чтобы узнать, какие у них могут быть подсказки.

Я подозреваю, что ваша единственная реальная проблема в первом трейсинговом файле заключается в том, что ваша система не получает первый сегмент(ы?) ответа сервера, содержащий ServerHello и другие данные (для 1.3 вероятно, включающий CCS EE и часть Cert), на обоих соединениях. Сообщение “Previous segment not captured” показывает, что Wireshark не увидел по крайней мере один сегмент, и последующий исходящий “Dup Ack … ack=1” подтверждает, что ваш стек ОС тоже его/их не увидел.

Версию протокола TLS нельзя определить только по ClientHello. Только объединение ClientHello с ServerHello позволяет Wireshark определить, используется ли TLS1.3, и отобразить его. Если Wireshark видит только ClientHello и не ServerHello, версия, которую он отображает, является произвольной и обычно неверной, и это следует игнорировать.

Итак, почему ваша система не получила первый сегмент(ы) сервера? Я не могу быть уверенным, но распространенная причина в том, если MTU установлен слишком низко на любой сети или канале, или (наоборот) MSS слишком высок на(?) узле, а фрагментация отключена или заблокирована, так что вы получаете сегмент(ы) TCP, который(е) длиннее допустимого датаграммы и отбрасывается. (На IPv6 фрагментации больше нет, так что последняя часть условия становится неактуальной.) Если вы развернете первые “Previous not captured” кадры и посмотрите на (относительный) номер последовательности в заголовке TCP, он покажет, сколько данных отсутствует, что равно размеру предыдущего сегмента, если он только один, или сумме размеров предыдущих сегментов, и поскольку неподтолкнутые сегменты обычно имеют одинаковый размер (MSS), сумма является небольшим целым числом, кратным размеру отдельных сегментов.

Если проблема заключалась бы в том, что ваша система по какой-то причине действительно отправляла приветствие TLSv1.0, чего не должно происходить по тем же причинам, которые вы указываете, ни один здравомыслящий сервер не отказался бы отвечать; если он не принимает 1.0 (а большинство хороших публичных серверов сегодня не принимают), он бы ответил либо оповещением, либо отключением (либо нормальным FIN, либо ненормальным RST), и все это было бы видно (и ясно различимо) в Wireshark.

Я нашел ответ. Он скрывался глубоко в настройках PPoE на моем маршрутизаторе, но профиль ppp был настроен на шифрование, которое в свою очередь имело change-tcp-mss=no

Как только я скорректировал профиль на нешифрованный с change-tcp-mss=yes, все заработало как ожидалось.

У меня была аналогичная проблема с настройкой vpn site-to-site с двумя Stormshield и доступом https через них.
Мы четко видели ту же ситуацию, когда отправитель не мог получить трафик, отправленный веб-сервером, и поэтому мы погрузились в исследование конфигурации MSS, наткнувшись на ваш пост.
Оказывается, у нас была PPoE связь на одной стороне нашего Stormshield для доступа к WAN, и мы установили TCP MSS на 1300 в меню “Application Protection > Protocols > IP Protocols > TCP-UDP” + отметили галочку “Impose MSS limit” и затем установили его на 1300, и после этого все заработало.
Таким образом, большое спасибо, потому что этот пост помог нам решить двухдневную проблему.

Я хочу добавить, что в дополнение к проблеме с доступом к веб-серверу у нас была другая проблема с доступом к серверу NAS (Synology) с помощью протоколов SMB/Netbios, и мы сумели подключить сетевые диски, но проводник Windows замерзал каждый раз, когда мы пытались получить доступ к документам. Это тоже решило эту проблему.

Удачного дня.