Eu tenho um novo servidor em uma sub-rede privada em um AWS VPC. Eu tenho uma instância de NAT na sub-rede pública do meu VPC e pode se conectar a servidores remotos bem. No entanto, quando eu tento arquivos scp, as coisas parecem travar.
ryan@sever-in-vpc:~ $ scp -vvvv myfile www1.domain.com:
...
debug2: exec request accepted on channel 0
Sending file modes: C0664 42625 myfile
debug2: channel 0: rcvd ext data 25
myfile 100% 42KB 41.6KB/s 00:00
Sink: C0664 42625 myfile
debug2: channel 0: written 25 to efd 6
debug1: client_input_channel_req: channel 0 rtype [email protected] reply 1
debug1: client_input_channel_req: channel 0 rtype [email protected] reply 1
O "..." inclui a verificação da chave do host, autenticação sucessiva, posso dar mais, se necessário. No lado remoto, agora tenho "myfile" no meu diretório home no servidor remoto com um tamanho de 0 bytes. A mensagem "debug1: client_input_channel_req: channel 0 rtype [email protected] resposta 1" é repetida aparentemente até eu matar o comando scp. (Deixei rodando por até cinco minutos ... "myfile" é apenas 42625 bytes.)
Parece-me que o lado que envia pensa que enviou todos os bytes, mas o lado receptor não os escreveu no disco.
Parece que o problema esse cara estava tendo, mas também não havia solução para ele. Alguma ideia de coisas que eu possa investigar?
Acontece que isso estava relacionado ao modo como eu configurei o VPC na AWS.
A descoberta automática de MTU deve funcionar, mas depende do retorno do tráfego ICMP. Acontece que, embora estivéssemos permitindo o ICMP em nossa sub-rede privada por meio dos grupos de segurança da AWS, não permitíamos o ICMP em nossa ACL de rede VPC. Abriu isso e o problema baseado em MTU desapareceu.
Certifique-se de verificar suas ACLs de VPC, além de seus grupos de segurança.
Tags scp