La command SCP se bloque lors du transfert de petits files

J'ai un nouveau server dans un sous-réseau privé dans un VPC AWS. J'ai une instance NAT dans le sous-réseau public de mon VPC, et je peux me connecter à des servers distants bien. Cependant, lorsque j'essaie de scp les files, les choses semblent se bloquer.

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 keepalive@openssh.com reply 1 debug1: client_input_channel_req: channel 0 rtype keepalive@openssh.com reply 1 

Le "…" comprend la vérification des keys de l'hôte, l'authentification réussie, je peux donner plus si nécessaire. Sur le côté distant, j'ai maintenant "myfile" dans mon directory personnel sur le server distant avec une taille de 0 octets. Le message "debug1: client_input_channel_req: channel 0 rtype keepalive@openssh.com répond 1" répète le message jusqu'à ce que je tue la command scp. (Je l'ai laissé fonctionner aussi longtime que cinq minutes … "myfile" est seulement 42625 octets.)

Il me semble que le côté émetteur pense qu'il est envoyé tous les octets, mais le côté réception n'a pas écrit sur le disque.

On ressemble au problème que ce type avait, mais pas de solution pour lui non plus. Des pensées pour les choses que je peux examiner?

Il s'avère que cela était lié à la façon dont j'ai installé VPC dans AWS.

L'auto-découverte de MTU devrait fonctionner, mais dépend du return du trafic ICMP. Il s'avère que, bien que nous autorisions ICMP dans notre sous-réseau privé via AWS Security Groups, nous n'acceptons pas ICMP dans notre ACL du réseau VPC. Ouvert et le problème basé sur MTU a disparu.

Assurez-vous donc de vérifier vos ACL VPC en plus de vos Groupes de security.