Problemas com o bloqueio do SCP durante a cópia do arquivo pela VPN

11

Tenho uma série de arquivos que preciso copiar via SCP através de uma VPN para um servidor Linux remoto todas as noites. Os arquivos não são grandes, estamos falando de dezenas de megabytes aqui, mas a cópia do arquivo quase sempre pára depois de alguns segundos. Executando o comando SCP com -vvv, vejo o seguinte repetidamente ao longo do processo de cópia tentada:

debug2: channel 0: rcvd adjust 131072
debug2: channel 0: rcvd adjust 131072
debug2: channel 0: rcvd adjust 131072

Alguma ideia? Eu vejo essa pergunta sendo feita em vários lugares por aí, mas nunca há respostas. Qualquer ajuda seria apreciada.

— MattC
fonte

Eu experimentei coisas semelhantes muitas vezes, embora não tenha nada que o faça de maneira confiável no momento. Pode ser interessante ver se o hpn-ssh faria alguma diferença.

— Sfink

7

Você está permitindo o ICMP através da VPN? "A conexão TCP é interrompida após alguns segundos" geralmente se traduz em " buraco negro da PMTU ".

— Gerald Combs
fonte

2

tão poucos entendem a descoberta PMTU do ICMP :-(

— The Janix Unix

2

Isso parece interessante, mas não é totalmente claro. Você poderia explicar o que exatamente está errado e como corrigi-lo?

— Craig McQueen

7

Semelhante à resposta de @ Gerald, esta página http://www.netheaven.com/pmtu.html fornece uma boa explicação sobre o MTU Discovery e as opções para enfrentar esse problema.

Também é um documento técnico da Cisco que discute a fragmentação de IP, a descoberta de MTU e o MSS, todos pertencentes aos túneis IPSec VPN, mas é igualmente válido para situações semelhantes. http://www.cisco.com/en/US/tech/tk827/tk369/technologies_white_paper09186a00800d6979.shtml

— jjcf89
fonte

1

Você está executando a versão mais recente de quaisquer servidores e clientes ssh que estiver usando? Eu também recomendo acessar suas listas de e-mail sobre isso, pois parece bastante obscuro.

— Mark C
fonte

1

Tivemos problemas similares no scp com alguns servidores Linux (Debian, 2.6.24-etchnhalf).

Conseguimos eliminar as paradas desativando a variável TCP tcp_sack ("reconhecimentos seletivos tcp") nos servidores remotos:

sysctl -w net.ipv4.tcp_sack=0

No Debian, o tcp_sack é ativado por padrão. Se eu li http://www.frozentux.net/ipsysctl-tutorial/chunkyhtml/tcpvariables.html , não faria sentido desabilitar essa opção, mas, no nosso caso, ajudou.

Você pode tornar essa alteração permanente adicionando uma linha net.ipv4.tcp_sack=0ao /etc/sysctl.conf (em outros sistemas Linux YMMV).

— voar
fonte

0

descubra o seu Path MTU

ping -M do -s 1472 host.domain
PING host.domain (10.0.0.1) 1472(1500) bytes of data.
ping: sendmsg: Message too long
ping: local error: Message too long, mtu=1196
^C
ping -M do -s 1168 host.domain
PING host.domain (10.0.0.1) 1168(1196) bytes of data.
1176 bytes from 10.0.0.1: icmp_seq=1 ttl=60 time=283 ms
^C

configure esse MTU para sua conexão de rede
```
ip link set eth0 mtu 1196
```
(note que isso é temporário)

— törzsmókus
fonte