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>

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

$ 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.

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

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

Интерфейсы

Вывод 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 ответа2

2

Это кажется проблемой с 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

2

Как уже писал 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

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .