TLS Handshake сбрасывается для некоторых веб-сайтов при использовании маршрутизатора OpenWRT

1070
Andrey Sapegin

В настоящее время я сталкиваюсь с очень странной проблемой с моим маршрутизатором. У меня TP-Link TL-WDR4300 rev. 1.7 работает OpenWRT 18.06.1.

Изначально проблема началась 1-2 месяца назад, когда у меня был OpenWRT 15.05, а последнее изменение конфигурации (до обновления до 18.06.1) на маршрутизаторе было около года назад.

Итак, 1-2 месяца назад я заметил, что некоторые сайты не загружаются на ВСЕ устройства (iPhone с iOS, телефон Android, ноутбук Ubuntu, ноутбук Windows) во ВСЕХ браузерах. Однако, если устройство отключено от WiFi и использует, например, сотовую сеть, веб-сайт загружается немедленно.

Мой провайдер - Deutsche Telekom, и хорошим примером веб-сайта, который не загружается, является https://telekom.de, который обычно ожидается доступным.

Я выполнил обновление до последней стабильной версии OpenWRT и начал расследование проблемы. Нет пропущенных пакетов в журналах или любых других сообщениях об ошибках на маршрутизаторе, которые связаны с проблемой. Curl может получить содержимое одного уязвимого веб-сайта (telekom.de) непосредственно на маршрутизаторе:

 root@OpenWrt:~# curl --tlsv1.0 -v https://telekom.de > GET / HTTP/1.1 > Host: telekom.de > User-Agent: curl/7.60.0 > Accept: */* >  < HTTP/1.1 301 Moved Permanently < Date: Sat, 01 Sep 2018 20:56:23 GMT < Server: Apache < Location: https://www.telekom.de/start < Content-Length: 236 < Content-Type: text/html; charset=iso-8859-1 <  <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <html><head> <title>301 Moved Permanently</title> </head><body> <h1>Moved Permanently</h1> <p>The document has moved <a href="https://www.telekom.de/start">here</a>.</p> </body></html>

На всех клиентах это все еще не работает:

$ curl --tlsv1.0 -v https://telekom.de * Rebuilt URL to: https://telekom.de/ * Hostname was NOT found in DNS cache * Trying 46.29.100.76... * Connected to telekom.de (46.29.100.76) port 443 (#0) * successfully set certificate verify locations: * CAfile: none CApath: /etc/ssl/certs * SSLv3, TLS handshake, Client hello (1): * Unknown SSL protocol error in connection to telekom.de:443  * Closing connection 0 curl: (35) Unknown SSL protocol error in connection to telekom.de:443

Я попытался подключить ноутбук с Windows напрямую к оптоволоконному модему PPPoE Deutsche Telekom, и веб-сайты начали нормально загружаться. Я также превратил ноутбук с Windows в маршрутизатор WiFi, и все клиенты смогли загрузить проблемные веб-сайты.

Моя первоначальная идея заключалась в том, что проблема может быть связана с IPv6 (другой, возможно, связан вопросом здесь ), и я настроил его (до этого не было правильно настроено). Это не помогло, а также отключение IPv6 в настройках адаптера для клиента Windows не помогает.

При использовании OpenWRT в качестве маршрутизатора браузер некоторое время пытается выполнить квитирование TLS (1-2 минуты), а затем показывает сообщение «сбой безопасного соединения».

Вот захват Wireshark рукопожатия TLS для telekom.de .

И ниже приведены некоторые из моих настроек маршрутизатора:

Снимок экрана с интерфейсами:

Interfaces

Вывод iptables -L -v (я не использую стандартную конфигурацию брандмауэра OpenWRT, поскольку он содержит много цепочек и слишком сложен для меня, поэтому я перезаписываю его при загрузке с помощью команды iptables-restore):

Chain INPUT (policy DROP 0 packets, 0 bytes) pkts bytes target prot opt in out source destination  5651 481K ACCEPT all -- lo any anywhere anywhere  137K 17M ACCEPT all -- any any anywhere anywhere ctstate RELATED,ESTABLISHED 184 10370 logdrop all -- any any anywhere anywhere ctstate INVALID 0 0 ACCEPT udp -- pppoe-wan any anywhere anywhere udp dpt:bootpc 0 0 ACCEPT udp -- l2tp-voip any anywhere anywhere udp dpt:bootpc 67318 4219K ACCEPT all -- br-lan any anywhere anywhere  5423 290K logdrop all -- any any anywhere anywhere   Chain FORWARD (policy DROP 0 packets, 0 bytes) pkts bytes target prot opt in out source destination  423K 49M ACCEPT all -- br-lan pppoe-wan anywhere anywhere  0 0 ACCEPT all -- br-lan l2tp-voip anywhere anywhere  0 0 ACCEPT all -- br-lan br-lan anywhere anywhere  1324K 1610M ACCEPT all -- pppoe-wan br-lan anywhere anywhere ctstate RELATED,ESTABLISHED 0 0 ACCEPT all -- l2tp-voip br-lan anywhere anywhere ctstate RELATED,ESTABLISHED 0 0 logdrop all -- any any anywhere anywhere   Chain OUTPUT (policy ACCEPT 188K packets, 25M bytes) pkts bytes target prot opt in out source destination   Chain logdrop (3 references) pkts bytes target prot opt in out source destination  5607 300K LOG all -- any any anywhere anywhere LOG level warning prefix "dropped: " 5607 300K DROP all -- any any anywhere anywhere

Вывод iptables -t nat -L -v :

Chain PREROUTING (policy ACCEPT 59800 packets, 4849K bytes) pkts bytes target prot opt in out source destination   Chain INPUT (policy ACCEPT 39692 packets, 2880K bytes) pkts bytes target prot opt in out source destination   Chain OUTPUT (policy ACCEPT 29226 packets, 2171K bytes) pkts bytes target prot opt in out source destination   Chain POSTROUTING (policy ACCEPT 2123 packets, 232K bytes) pkts bytes target prot opt in out source destination  35523 2660K MASQUERADE all -- any pppoe-wan anywhere anywhere  2 1098 MASQUERADE all -- any l2tp-voip anywhere anywhere

Содержимое / etc / config / network:

cat /etc/config/network  config interface 'loopback' option ifname 'lo' option proto 'static' option ipaddr '127.0.0.1' option netmask '255.0.0.0'  config globals 'globals' option ula_prefix 'xxxx:xxxx:xxxx:xxxx::/64'  config interface 'lan' option ifname 'eth0.1' option type 'bridge' option proto 'static' option ipaddr '192.168.x.x' option netmask '255.255.255.0' option ip6addr 'xxxx:xxxx:xxxx:xxxx::1/64'  config interface 'wan' option proto 'pppoe' option password 'yyyyyyyy' option ifname 'eth0.7' option username 'zzzzzzzzzzzzzzzzzzzzzzzzzzz@t-online.de' option ipv6 '1'  config interface 'wan6' option ifname '@wan' option proto 'dhcpv6' option reqprefix 'auto' option reqaddress 'try'  config switch option name 'switch0' option reset '1' option enable_vlan '1'  config switch_vlan option device 'switch0' option vlan '1' option vid '1' option ports '0t 2 3 4 5'  config switch_vlan option device 'switch0' option vlan '3' option vid '7' option ports '0t 1t'  config interface 'voip' option proto 'l2tp' option server 'ooo.ooo.ooo.ooo' option username 'xxxxxxxxxxx' option password 'xxxxxxxxxxx' option defaultroute '0' option peerdns '0' option delegate '0' option ipv6 '0'  config route option interface 'voip' option target 'xxxxxxxxxxxxxxx' option netmask 'xxxxxxxxxxx' option gateway 'xxxxxxxxxx'

Что может быть причиной этой проблемы?

Обновление: Следуя предложениям из аналогичного вопроса, я попытался установить разные MTU (1400, 1476, 1480) для pppoe-wan ( ifconfig pppoe-wan mtu xxxx ). К сожалению, это не помогло.

Обновление 2: на ubuntuforums.org аналогичная проблема была исправлена ​​путем переустановки Ubuntu. Я только что попытался повторно прошить OpenWRT (следуя https://openwrt.org/toh/tp-link/tl-wdr4300#flash_overwrite ; затем я применил свою конфигурацию). К сожалению, это не помогло.

5
«Я не использую стандартную конфигурацию OpenWRT», и что происходит, когда вы создаете резервную копию своей конфигурации, используете ее по умолчанию и используете стандартные правила Luci iptables? Tim_Stewart 6 лет назад 2
В вашем отрывке curl пытается использовать SSLv3. SSLv3 мертв. Скорее всего, это совершенно не связано с вашим маршрутизатором. Daniel B 6 лет назад 0
@Daniel B, спасибо, я обновил вопрос и выложил туда вывод curl с TLS 1.0 Andrey Sapegin 6 лет назад 0
`--tlsv1.0` устарела. Пожалуйста, замените в своем сообщении вывод curl на клиенте и захват Wireshark одним, используя `--tlsv1.2` или хотя бы` --tlsv1.1`. harrymc 6 лет назад 0
Захват Wireshark был сделан для Firefox на Windows. Если я попробую curl с --tlsv1.2 или --tlsv1.1, результат будет абсолютно таким же. Andrey Sapegin 6 лет назад 0
Хорошая деталь !!!!!! Pimp Juice IT 6 лет назад 0
Конфигурация по умолчанию работает? SILENT 6 лет назад 0

2 ответа на вопрос

2
RalfFriedl

Это кажется проблемой с MTU и фрагментацией. MTU для Ethernet составляет 1500, а для PPPoE MTU (1500-8) = 1492.

Установка MTU только на маршрутизаторе не помогает. Вы уменьшаете установленный размер MSS в исходящих пакетах.

Добавьте это правило iptables, если ppp0ваш интерфейс PPPoE:

-A FORWARD -o ppp0 -p tcp -m tcp --tcp-flags SYN, RST SYN -j TCPMSS --clamp-mss-to-pmtu

Альтернативой является фиксированный размер:

-A FORWARD -o ppp0 -p tcp -m tcp --tcp-flags SYN, RST SYN -j TCPMSS --set-mss 1400

Да ты прав! Я только что нашел его и предоставлю еще один ответ с более подробной информацией по этому вопросу. Вы все еще получаете принятый ответ и все щедрые баллы, большое спасибо! Andrey Sapegin 6 лет назад 0
2
Andrey Sapegin

Как уже писал RalfFriedl, это действительно проблема MTU. Однако простое изменение MTU не помогает. У PPPoE всегда меньше MTU Ethernet, например, Ethernet MTU 1488 -> PPPoverEthernet MTU 1480. Почему-то, даже если маршрутизатор знает правильный MTU для PPPoE, и он будет работать, если соединение инициируется с самого маршрутизатора, все клиентские машины будет по-прежнему отправлять пакеты с MTU 1500, и iptables должен знать, что при пересылке пакетов необходима настройка MTU.

Вот подробное описание проблемы: это 2017 год - почему я все еще должен заботиться о MTU?

По умолчанию в OpenWRT есть специальная опция для устранения этой проблемы:

Однако, даже с нестандартными правилами iptables, это легко исправить с помощью параметра --set-mss в iptables.

Важным моментом является то, что это правило ограничения mss должно быть в начале правил FORWARD, чтобы избежать захвата пакетов другими правилами ранее (например, правилами conntrack и т. Д.)

В моем случае это первое правило:

-A FORWARD -i br-lan -o pppoe-wan -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

Похожие вопросы