OpenVPN trabalhando com TCP não com UDP

5

Eu configurei com sucesso um servidor OpenVPN no Debian (raspberry pi model b +). Com o protocolo definido para TCP funciona exatamente como desejado (internet roteada através de VPN, acesso a máquinas de rede local), porém quando eu definir o protocolo para UDP (que eu acho que seria desejável para melhor velocidade), então eu acho que eu sou capaz de ping de qualquer host (endereço IP ou nome de domínio), eu posso telnet e ssh (novamente endereço IP ou domínio), mas quando tento abrir uma página em um navegador, parece fazer uma conexão inicial, mas nunca carrega.

Você tem alguma ideia de por que a navegação na web seria um problema para o modo UDP?

Eu configurei o UFW para gerenciar o iptables, a principal linha de configuração para isso foi adicionada a before.rules

*nat
:PREROUTING ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
# Allow traffic from OpenVPN client to eth0
-A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE
COMMIT

Como tudo funciona corretamente para o TCP e quase propriamente para o UDP, acho que o problema não está no firewall / iptables, mas posso estar errado.

Minha configuração do servidor openvpn é

local 192.168.0.31
dev tun
proto tcp
port 1194
ca ca.crt
cert server.crt
key server.key
dh dh1024.pem
server 10.8.0.0 255.255.255.0
ifconfig 10.8.0.1 10.8.0.2
push "route 10.8.0.31 255.255.255.255"
push "route 10.8.0.0 255.255.255.0"
push "route 192.168.0.31 255.255.255.0"
push "dhcp-option DNS 192.168.0.1"
push "redirect-gateway def1"
push "explicit-exit-notify 3"
client-to-client
duplicate-cn
keepalive 10 120
tls-auth ta.key 0
cipher AES-128-CBC
comp-lzo
user nobody
group nogroup
persist-key
persist-tun
status /var/log/openvpn-status.log 20
log /var/log/openvpn.log
verb 1

Alguém tem alguma idéia de por que pode haver um problema?

    
por beacon_bonanza 12.08.2015 / 10:50

1 resposta

11

Estes sintomas específicos (com uma VPN) são sintomas bastante comuns que indicam um problema com o MTU do seu caminho.

Noções básicas de MTU

O caminho MTU (Maximum transmission unit) é o maior pacote que pode atravessar dois dispositivos na internet (ou qualquer outra rede). Cada link ao longo do caminho tem seu próprio MTU, que pode ou não corresponder aos outros. A MTU do caminho geral é a MTU mais baixa ao longo de todo o caminho.

Se o seu computador tentar enviar um pacote maior que o MTU do caminho, o pacote de dados será descartado no salto, e os dados nunca chegarão. Em redes bem comportadas, seu computador deve receber uma resposta de erro e saber ajustar automaticamente a MTU para baixo e / ou fragmentar os pacotes subsequentes. Em redes mal comportadas, pode ser descartado silenciosamente.

Descoberta MTU (automática) do caminho é o mecanismo usado para detectar automaticamente o MTU entre você e o servidor VPN, no entanto é mais robusto com o TCP do que com o UDP em redes mal comportadas, porque o TCP exige um feedback explícito que pode dizer quais pacotes não chegam.

A razão pela qual ele age da maneira como funciona com links VPN é porque os cabeçalhos de encapsulamento VPN reduzem o MTU da sua conexão tunnelled e porque o UDP não fornece nenhum feedback sobre pacotes descartados.

Se a sua PMTU real for, por exemplo, 1400 bytes, o envio de um pacote de 1400 bytes por meio de uma VPN pode levar 1432 bytes. Em uma conexão TCP, se você tentar enviar um pacote de 1432 bytes, o TCP pode dizer que não chega e o fragmenta e envia novamente como um pacote de 1400 bytes e um segundo pacote de 32 bytes (isso é uma simplificação grosseira). Com o UDP, ele é descartado silenciosamente. No entanto, em ambos casos, o envio de qualquer pacote menor que 1400 bytes será bem-sucedido.

É por isso que o SSH e o telnet funcionam, enquanto a navegação na Web não funciona. Sua VPN reduziu sua MTU abaixo do seu padrão, mas seu sistema operacional não percebeu porque as mensagens de erro não estão sendo retornadas corretamente ou a descoberta automática da PMTU não está funcionando. Mas como SSH e telnet e ping usam pacotes muito pequenos (normalmente < 100 bytes), se seu MTU foi reduzido de 1400 para 1368 (1400 - 32), não importa, pois eles ainda são muito menores que os limite. O SSH e o telnet geralmente enviam entre um byte e uma linha por vez, além de cabeçalhos de pacote. Os pacotes de ping são normalmente de até 64 bytes mais cabeçalhos de pacote, novamente muito menores do que qualquer outro MTU (1400+)

A navegação na Web inicialmente se conecta porque o DNS, os pacotes TCP SYN / ACK e as solicitações HTTP são geralmente muito menores que 1400 bytes, mas assim que o site tentar enviar a página da web, ele usará pacotes de tamanho normal. que então são descartados silenciosamente ao longo do caminho.

Resolvendo o problema

Existe a maneira fácil (barata) e a outra maneira que envolve descobrir qual é o problema.

O modo mais barato de configurar o MTU é muito menor manualmente - por exemplo, para 1000, então tudo se encaixa dentro da MTU reduzida da VPN. Isso em si é um bom teste para ver se o MTU é o problema.

A melhor maneira seria descobrir onde está o problema e corrigi-lo. Os problemas de descoberta automática da MTU podem surgir devido a um servidor de baixa qualidade ou ISP, sobre o qual você não pode fazer nada, ou problemas locais de firewall / configuração, que podem ser corrigidos. Pode ser o seu roteamento OpenVPN e as regras de firewall não estão permitindo que as mensagens de erro ICMP voltem à sua máquina.

Um método intermediário seria descobrir o MTU máximo real e definir isso manualmente - você pode começar com algo pequeno como 1000 bytes e trabalhar para cima para encontrar o valor mais alto que funciona. Basicamente, conecte sua VPN usando o UDP e pingue algo através da VPN com o comando ping -f <server address> -l <packet size> e aumente o tamanho do pacote até que ele pare de funcionar - seja com um tempo limite ou com um erro.

    
por 13.08.2015 / 13:03

Tags