Eu configurei um túnel SIT 6to4 no MikroTik seguindo o exemplo do Hurricane Electric nos arquivos de ajuda do MikroTik .
Funcionou, mas a conexão com alguns recursos era extremamente lenta e muitas vezes expirava. Por exemplo, as velocidades de download dos servidores padrão durante a atualização e reconfiguração do guix permaneceram em torno de 50 KiB/s e normalmente falharam ao baixar o kernel, provavelmente porque é um pacote grande.
O suporte técnico do corretor de túnel sugeriu que o MTU de 1280 é muito pequeno e 1480 deveria ser usado. Na verdade, se eu alterar o MTU da interface do túnel para esse valor, a velocidade da conexão se tornará normal e contará em MiBs. Não sei por que isso funciona, mas provavelmente porque em algum momento o equipamento de rede não precisa quebrar os pacotes maiores em fragmentos menores, o que exigiria alguma sobrecarga.
Mas me deparo com um problema diferente: as conexões com alguns servidores são interrompidas. guix pulltrava. A execução curl -vem uma URL problemática resulta no tempo limite da negociação TLS ( curl: (28) SSL connection timeout) ou em uma falha da biblioteca de criptografia ( curl: (35) gnutls_handshake() failed: Помилка у функції pull.).
O ping no servidor funciona, mas o ping com uma mensagem do tamanho do MTU ( ping6 -sseguido pelo número de octetos) recebe uma resposta Packet too bigpara o primeiro ping e depois descarta o restante. Uma conexão TCP é bem-sucedida, mas a negociação TLS atinge o tempo limite. A MTU é muito grande para a conexão com este servidor.
RFC 4213 fornece:
Um nó que usa MTU de túnel estático trata a interface do túnel como tendo uma MTU de interface fixa. Por padrão, o MTU DEVE estar entre 1280 e 1480 bytes (inclusive), mas DEVE ter 1280 bytes.
O RFC 6343 tem uma seção sobre "Falha no PMTUD", vinculada ao RFC 2923 , sugerindo voltar ao MTU 1280 para IPv6, a menos que seja possível consertar "o buraco negro do ICMP".
O exemplo de configuração do MikroTik sugere o uso de 1280 para evitar a necessidade de negociação de MTU. Há também clamp-tcp-mssuma configuração que está ativada por padrão:
Controla se o tamanho do MSS deve ser alterado para pacotes TCP SYN recebidos. Quando ativado, um roteador alterará o tamanho do MSS para pacotes TCP SYN recebidos se o tamanho do MSS atual exceder o MTU da interface do túnel (levando em consideração a sobrecarga do TCP/IP). O pacote encapsulado recebido ainda conterá o MSS original e somente após o desencapsulamento o MSS será alterado.
Isso pode explicar por que o ping ocasionalmente me permite enviar mensagens enormes até 65.527 (aparentemente 65.535 menos 8) pelo túnel. No entanto, isso tenta corresponder ao MTU do túnel enquanto preciso determinar o MTU por conexão, que pode ser menor que o MTU do túnel. Como faço isso para não precisar diminuir o MTU do meu túnel?
Parece que a configuração padrão no MikroTik para IPv6 não possui caminho de descoberta de MTU . Adicionar esta regra ao firewall IPv6 ajudou ( fonte ):
O significado das opções :
Assim, a regra tenta descobrir o MTU para cada nova conexão. (A descrição citada acima é aparentemente para IPv4. A especificação IPv6 espera que não haja fragmentação, portanto nenhum bit DF pode ser usado.)