Рукостискання TLS скидається для деяких веб-сайтів, коли використовується маршрутизатор OpenWRT


5

В даний час я стикаюся з дуже дивною проблемою з моїм маршрутизатором. У мене є 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>

На всіх клієнтах він ще не працював: \ t

$ 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 ; потім я застосував свою конфігурацію). На жаль, це не допомогло.


2
"Я не використовую стандартну конфігурацію OpenWRT", і що відбувається, коли ви створюєте резервні копії конфігурації, заводські налаштування за замовчуванням і використовуєте стандартні правила Luci iptables?
Tim_Stewart

У вашій витримці curl намагається використовувати SSLv3. SSLv3 мертвий. Швидше за все, це абсолютно не пов'язане з вашим маршрутизатором.
Daniel B

@Daniel B, спасибі, я оновив питання і поставив там вихід curl з TLS 1.0
Andrey Sapegin

--tlsv1.0 тепер застаріло. Будь ласка, замініть у своєму повідомленні вихід curl на клієнті і захоплення Wireshark одним використанням --tlsv1.2 або принаймні --tlsv1.1.
harrymc

Захоплення Wireshark було зроблено для Firefox у Windows. Якщо я спробую curl з --tlsv1.2 або --tlsv1.1, висновок абсолютно однаковий.
Andrey Sapegin

Відповіді:


2

Це, здається, проблема з MTU і фрагментацією. Ethernet MTU становить 1500, тоді як PPPoE MTU становить (1500-8) = 1492.

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

Додайте це правило до iptables, припускаючи ppp0 Ваш інтерфейс PPPoE:

-A FORWARD -o ppp0 -p tcp -m tcp --tcp-прапорці SYN, RST SYN -j TCPMSS --клап-mss-to-pmtu

Альтернативою є фіксований розмір:

-A FORWARD -o ppp0 -p tcp -m tcp --tcp-прапори SYN, RST SYN -j TCPMSS - set-mss 1400


Так, ти маєш рацію! Я тільки що знайшов його, і я дам ще одну відповідь з більш детальною інформацією про проблему. Ви все ще отримаєте прийняту відповідь і всі бали за великі гроші, велике спасибі!
Andrey Sapegin

2

Як уже писав RalfFriedl, це дійсно проблема MTU. Однак проста зміна MTU не допомагає. PPPoE завжди має менший MTU Ethernet, наприклад. Ethernet MTU 1488 - & gt; 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
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.