O Handshake TLS é redefinido para alguns sites ao usar o roteador OpenWRT

4

Atualmente estou enfrentando um problema muito estranho com meu roteador. Eu tenho TP-Link TL-WDR4300 rev. 1.7 executando o OpenWRT 18.06.1.

O problema começou originalmente 1-2 meses atrás, quando eu tinha o OpenWRT 15.05, e a última alteração de configuração (antes da atualização para 18.06.1) no roteador foi há cerca de um ano.

Então, há 1-2 meses, notei que alguns sites não são carregados em TODOS os dispositivos (iPhone com iOS, telefone Android, laptop Ubuntu, laptop Windows) em TODOS os navegadores. No entanto, se o dispositivo estiver desconectado do Wi-Fi e usar, por exemplo, a rede celular, o site carrega imediatamente.

Meu ISP é a Deutsche Telekom, e um bom exemplo de um site que não está sendo carregado é o link , que normalmente deve ser acessado.

Realizei a atualização para a última versão estável do OpenWRT e iniciei a investigação do problema. Não há pacotes descartados em logs ou quaisquer outras mensagens de erro no roteador relacionadas ao problema. Curl é capaz de obter o conteúdo de um site afetado (telekom.de) diretamente no roteador:

 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>

Em todos os clientes, ainda não funcionou:

$ 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

Eu tentei conectar o laptop Windows diretamente ao modem de fibra ótica PPPoE da Deutsche Telekom e os sites da Web começaram a carregar normalmente. Eu também transformei um laptop Windows em roteador WiFi e todos os clientes puderam carregar sites problemáticos.

Minha ideia original era que o problema poderia estar relacionado ao IPv6 (outro problema possivelmente relacionado é here ), e eu configurei-o (antes que ele não estivesse configurado corretamente). Não ajudou, e também desabilitar o IPv6 nas configurações do adaptador para o cliente Windows não ajuda.

Ao usar o OpenWRT como um roteador, o navegador tenta realizar um handshake de TLS por um tempo (1-2 minutos) e, em seguida, mostra a mensagem "conexão segura falhou".

Aqui está a captura Wireshark de handshake TLS para telekom.de .

E abaixo estão algumas das configurações do meu roteador:

Captura de tela de interfaces:

Saídadeiptables-L-v(nãousoaconfiguraçãodefirewallpadrãodoOpenWRT,poiscontémmuitascadeiaseémuitocomplicadoparamim,entãoeureescrevê-lonainicializaçãoviacomandoiptables-restore):

ChainINPUT(policyDROP0packets,0bytes)pktsbytestargetprotoptinoutsourcedestination5651481KACCEPTall--loanyanywhereanywhere137K17MACCEPTall--anyanyanywhereanywherectstateRELATED,ESTABLISHED18410370logdropall--anyanyanywhereanywherectstateINVALID00ACCEPTudp--pppoe-wananyanywhereanywhereudpdpt:bootpc00ACCEPTudp--l2tp-voipanyanywhereanywhereudpdpt:bootpc673184219KACCEPTall--br-lananyanywhereanywhere5423290Klogdropall--anyanyanywhereanywhereChainFORWARD(policyDROP0packets,0bytes)pktsbytestargetprotoptinoutsourcedestination423K49MACCEPTall--br-lanpppoe-wananywhereanywhere00ACCEPTall--br-lanl2tp-voipanywhereanywhere00ACCEPTall--br-lanbr-lananywhereanywhere1324K1610MACCEPTall--pppoe-wanbr-lananywhereanywherectstateRELATED,ESTABLISHED00ACCEPTall--l2tp-voipbr-lananywhereanywherectstateRELATED,ESTABLISHED00logdropall--anyanyanywhereanywhereChainOUTPUT(policyACCEPT188Kpackets,25Mbytes)pktsbytestargetprotoptinoutsourcedestinationChainlogdrop(3references)pktsbytestargetprotoptinoutsourcedestination5607300KLOGall--anyanyanywhereanywhereLOGlevelwarningprefix"dropped: "
5607  300K DROP       all  --  any    any     anywhere             anywhere

Saída de 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 

Conteúdo de / 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 '[email protected]'
 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'

O que pode ser um motivo para esse problema?

Atualização: Seguindo as sugestões da pergunta semelhante , tentei definir MTUs diferentes (1400 , 1476, 1480) para pppoe-wan ( ifconfig pppoe-wan mtu xxxx ). Infelizmente, isso não ajudou.

Atualização 2: No ubuntuforums.org , um problema semelhante foi corrigido via reinstalar o Ubuntu. Acabei de tentar reaparecer o OpenWRT (seguindo o link ; depois apliquei minha configuração). Infelizmente isso não ajudou.

    
por Andrey Sapegin 30.08.2018 / 23:00

2 respostas

2

Isso parece ser um problema com o MTU e a fragmentação. A Ethernet MTU é 1500, enquanto a PPPoE MTU é (1500-8) = 1492.

Definir o MTU no roteador sozinho não ajuda. Você reduz o ajuste do tamanho do MSS nos pacotes de saída.

Adicione esta regra a iptables , assumindo que ppp0 é sua interface PPPoE:

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

Uma alternativa é um tamanho fixo:

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

    
por 03.09.2018 / 22:41
2

Como RalfFriedl já escreveu, é de fato o problema da MTU. No entanto, a simples mudança de MTU não ajuda. PPPoE sempre tem menos MTU Ethernet, por ex. Ethernet MTU 1488 - > PPPoverEthernet MTU 1480. De alguma forma, mesmo que o roteador conheça a MTU correta para PPPoE, e funcione caso a conexão seja iniciada pelo próprio roteador, todas as máquinas clientes ainda enviarão pacotes com MTU 1500 e o iptables precisará saber que o ajuste da MTU é necessário ao encaminhar os pacotes.

Aqui está a descrição detalhada do problema: É 2017 - Por que ainda tenho que me preocupar com a MTU?

Por padrão, o OpenWRT tem uma opção especial para atenuar esse problema:

No entanto, mesmo com regras não iptables stadard, isso pode ser facilmente corrigido usando a opção --set-mss em iptables

O ponto importante é que essa regra de fixação de mss deve estar no início das regras FORWARD , para evitar que os pacotes sejam capturados por outras regras antes (por exemplo, regras conntrack, etc.)

No meu caso, esta é a primeira regra lá:

-A FORWARD -i br-lan -o pppoe-wan -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
    
por 03.09.2018 / 22:58