У меня есть новый сервер в частной подсети в AWS VPC. У меня есть экземпляр NAT в общедоступной подсети моего VPC, и я могу нормально подключаться к удаленным серверам. Однако, когда я пытаюсь скопировать файлы scp, кажется, что все зависает.
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
"..." включает проверку ключа хоста, успешную аутентификацию, при необходимости я могу дать больше. На удаленной стороне у меня теперь есть «myfile» в моем домашнем каталоге на удаленном сервере размером 0 байт. Сообщение «debug1: client_input_channel_req: channel 0 rtype keepalive@openssh.com reply 1», похоже, повторяется, пока я не убью команду scp. (Я оставил его работать на пять минут ... "myfile" занимает всего 42625 байт.)
Мне кажется, что отправляющая сторона думает, что отправила все байты, но получающая сторона не записала их на диск.
Похоже на проблему этот парень был, но и для него не было решения. Есть какие-нибудь мысли о том, что я могу изучить?
Оказывается, это было связано с тем, как я настроил VPC в AWS.
Автоматическое обнаружение MTU должно работать, но зависит от обратного трафика ICMP. Оказывается, хотя мы разрешали ICMP в нашу частную подсеть через группы безопасности AWS, мы не разрешали ICMP в нашем ACL сети VPC. Открыл это, и проблема с MTU ушла.
Поэтому не забудьте проверить списки ACL VPC в дополнение к группам безопасности.