Certos sites da Web HTTPS não são carregados da máquina virtual KVM por IPv6

Question

Isso está me enlouquecendo, já que não consigo carregar determinados sites HTTPS somente de máquinas virtuais KVM e apenas sobre IPv6. O IPv4 funciona bem. A conectividade IPv6 funciona para os mesmos sites do hipervisor.

Minha configuração

• O hypervisor KVM está sendo executado no Ubuntu 14.04.5 LTS .
• eth0 é adicionado à interface da ponte br0 e eu uso essa ponte para conectar as VMs ao mundo externo.
• Duas VMs estão sendo executadas no hipervisor. O primeiro está sendo executado no Ubuntu 12.04 (eu sei que ele atingiu o EOL, mas isso não é motivo de preocupação), e o segundo é um Ubuntu 16.04 . Ambas as VMs experimentam o problema.
• As VMs estão usando uma interface do Virtio para se conectar à rede.
• Endereços IPv6 são obtidos pelo hipervisor e pelas VMs.
• Meu servidor DNS está retornando endereços IPv6 se suportado por um domínio, caso contrário, ele funciona com o IPv4.

• Eu não tenho firewall (ip6tables) para o IPv6 nem para o hipervisor nem para as VMs.

  # ip6tables -v -L -n 
  Chain INPUT (policy ACCEPT 196K packets, 32M bytes)
  pkts bytes target     prot opt in     out     source               destination         
  
  Chain FORWARD (policy ACCEPT 5007K packets, 3858M bytes)
  pkts bytes target     prot opt in     out     source               destination         
  
  Chain OUTPUT (policy ACCEPT 185K packets, 30M bytes)
  pkts bytes target     prot opt in     out     source               destination         
  
  
  # ip6tables -v -L -n -t nat
  Chain PREROUTING (policy ACCEPT 1749 packets, 181K bytes)
  pkts bytes target     prot opt in     out     source               destination         
  
  Chain INPUT (policy ACCEPT 135 packets, 24165 bytes)
  pkts bytes target     prot opt in     out     source               destination         
  
  Chain OUTPUT (policy ACCEPT 187 packets, 27578 bytes)
  pkts bytes target     prot opt in     out     source               destination         
  
  Chain POSTROUTING (policy ACCEPT 1801 packets, 185K bytes)
  pkts bytes target     prot opt in     out     source               destination
  

O problema

• A conectividade IPv6 (e IPv4) funciona para todos os sites do hipervisor (tudo bem e como esperado).

  # wget https://lwn.net -O - > /dev/null; echo Exit code: $?
  --2017-08-02 18:55:47--  https://lwn.net/
  Resolving lwn.net (lwn.net)... 2600:3c03::f03c:91ff:fe61:5c5b, 45.33.94.129
  Connecting to lwn.net (lwn.net)|2600:3c03::f03c:91ff:fe61:5c5b|:443... connected.
  HTTP request sent, awaiting response... 200 OK
  Length: 25202 (25K) [text/html]
  Saving to: ‘STDOUT’
  
  100%[=====================================>] 25,202       149KB/s   in 0.2s   
  
  2017-08-02 18:55:48 (149 KB/s) - written to stdout [25202/25202]
  
  Exit code: 0
  

• A conectividade IPv6 funciona para a maioria dos sites que experimentei de dentro das VMs, mas não de todas. Por exemplo, link e link são dois sites https com os quais tenho problemas. Como você pode ver no comando wget abaixo, a conexão atinge um estado conectado , mas fica preso lá:

  # wget https://lwn.net -O - > /dev/null; echo Exit code: $?
  --2017-08-02 18:53:40--  https://lwn.net/
  Resolving lwn.net (lwn.net)... 2600:3c03::f03c:91ff:fe61:5c5b, 45.33.94.129
  Connecting to lwn.net (lwn.net)|2600:3c03::f03c:91ff:fe61:5c5b|:443... connected.
  

O que tentei resolver o problema até agora

1. Começou com o ping6. Curiosamente, os pings das VMs estão funcionando para todos os domínios ao usar o IPv6! Incluindo os que https não está funcionando.

   # ping6 -c 1 -n hioa.no 
   PING hioa.no(2001:700:700:2::65) 56 data bytes
   64 bytes from 2001:700:700:2::65: icmp_seq=1 ttl=53 time=88.7 ms
   
   # ping6 -c 1 -n lwn.net
   PING lwn.net(2600:3c03::f03c:91ff:fe61:5c5b) 56 data bytes
   64 bytes from 2600:3c03::f03c:91ff:fe61:5c5b: icmp_seq=1 ttl=54 time=145 ms
   

2. Eu tentei mudar os dispositivos de rede virtual do virtio para e1000 . Problema ainda existe.

3. Tentei conectar-me ao IPv4 nos sites com os quais enfrentei o problema.

   # dig A lwn.net
   
   ; <<>> DiG 9.10.3-P4-Ubuntu <<>> A lwn.net
   ;; global options: +cmd
   ;; Got answer:
   ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41423
   ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
   
   ;; OPT PSEUDOSECTION:
   ; EDNS: version: 0, flags:; udp: 4096
   ;; QUESTION SECTION:
   ;lwn.net.                       IN      A
   
   ;; ANSWER SECTION:
   lwn.net.                2633    IN      A       45.33.94.129
   

   A conectividade IPv4 funciona bem!

   # wget --no-check-certificate https://45.33.94.129 -O - > /dev/null; echo Exit code: $?
   --2017-08-02 18:41:32--  https://45.33.94.129/
   Connecting to 45.33.94.129:443... connected.
       WARNING: certificate common name '*.lwn.net' doesn't match requested host name '45.33.94.129'.
   HTTP request sent, awaiting response... 200 OK
   Length: 25226 (25K) [text/html]
   Saving to: 'STDOUT'
   
   100%[==================================>] 25,226       137K/s   in 0.2s    
   
   2017-08-02 18:41:33 (137 KB/s) - written to stdout [25226/25226]
   
   Exit code: 0
   

4. Tentou usar o "openssl s_client" para conectar e ver se há alguma mensagem de erro, mas o "openssl s_client" ainda não suporta o IPv6 (pelo menos não na versão openssl incluída no Ubuntu 16.04) .

5. Verificado dmesg e / var / log / syslog mas não há nada relacionado aqui.

Alguém tem uma ideia de por que obtenho esse comportamento estranho em alguns sites? Alguma orientação sobre o que eu deveria tentar investigar em seguida?

    

Answer 1

Problema resolvido reduzindo o MTU para 1492 nas VMs. O hipervisor é responsável por estabelecer uma conexão PPPoE com a Internet, e a interface ppp0 tem uma MTU de 1492 bytes.

Ainda assim, por que a MTU seria um problema, já que tanto o IPv4 quanto o IPv6 implementam a descoberta do MTU do caminho? Então, por que a descoberta do caminho MTU não está funcionando neste caso (somente para alguns destinos IPv6)?

Parece que encontro uma situação de buraco negro aqui.

Capturei algum tráfego com tcpdump e carreguei o arquivo no Wireshark. Observei que a conexão passa pelo handshake de três vias TCP, como você pode ver na figura anexada (pacote 1-3). Isso também é óbvio a partir da saída wget na minha pergunta, onde como você pode ver, o wget fica preso depois que ele imprime uma mensagem connected . Após o handshake de três vias bem-sucedido, o cliente (minha VM) envia uma mensagem SSL "Client Hello" , mas nunca recebe um " Server Hello " de volta. O que o cliente recebe é um pacote que está obviamente fora de ordem com base no número de sequência do TCP (o wireshark também reporta [TCP Segmento anterior não capturado], Dados de Continuação ). O cliente então responde com um ACK (pacote 6) para o último pacote em ordem que foi recebido (um ACK duplicado) e a conexão para desde que o servidor tente reenviar o pacote perdido que é maior do que o MTU suportado e nunca chega. Então a conexão fica presa lá até que eu pressione Ctrl + C onde a terminação da conexão é iniciada (pacotes 8-10).

Então,porqueadescobertadaMTUdoPathnãoestáapenasfuncionandoparaalgunsdestinosIPv6(nãotodos),masnãohánenhumproblemacomoIPv4?Paraessapergunta,edesdequeminhainstalaçãonãotemnenhumfirewallIPv6,suponhoquehajaalgumfirewallnocaminhoparacertossitesquebloqueiao Mensagens muito grandes do pacote ICMPv6 que são necessárias para que a descoberta da MTU do caminho funcione. O interessante é que os pacotes de ping ICMPv6 simples passam e eu até recebo respostas.