web-dev-qa-db-ja.com

VPNを介したファイルのコピー中にSCPが停止する問題

私は毎晩、SCPを介してVPN経由でリモートLinuxサーバーにコピーする必要がある一連のファイルを持っています。ファイルは大きくありません。ここでは数十メガバイトについて話していますが、ファイルのコピーはほとんど常に数秒後に停止します。 -vvvを指定してSCPコマンドを実行すると、試行されたコピープロセス全体で次のメッセージが繰り返し表示されます。

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

何かご意見は?私はこの質問がさまざまな場所で尋ねられるのを見ますが、答えはありません。任意の助けいただければ幸いです。

11
MattC

VPNを介したICMPを許可していますか? 「TCP接続が数秒後に停止する」は、しばしば「 PMTUブラックホール 」に変換されます。

7
Gerald Combs

@Geraldの応答と同様に、このページ http://www.netheaven.com/pmtu.html は、この問題に直面した場合のMTU検出とオプションの適切な説明を提供します。

また、IPフラグメンテーション、MTUディスカバリ、およびMSSについてすべてIPSec VPNトンネルに関連するが、同様の状況でも同等に有効である、シスコによるホワイトペーパー。 http://www.Cisco.com/en/US/tech/tk827/tk369/technologies_white_paper09186a00800d6979.shtml

7
jjcf89

一部のLinuxサーバー(Debian、2.6.24-etchnhalf)と同様のscpの問題が発生しました。

リモートサーバーでTCP変数tcp_sack( "tcp選択的確認応答")を無効にすることで、ストールを回避できました。

sysctl -w net.ipv4.tcp_sack=0

Debianでは、tcp_sackはデフォルトで有効になっています。 http://www.frozentux.net/ipsysctl-tutorial/chunkyhtml/tcpvariables.html を読んだ場合、このオプションを無効にしても意味がありませんが、私たちの場合は役に立ちました。

/etc/sysctl.confにnet.ipv4.tcp_sack=0という行を追加することで、この変更を永続的にすることができます(他のLinuxシステムではYMMV)。

1
flight

使用しているsshサーバーおよびクライアントの最新バージョンを実行していますか?また、あいまいに見えるため、この件についてメーリングリストにアクセスすることをお勧めします。

1
Mark C
  1. パス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
    
  2. ネットワーク接続用にそのMTUをセットアップする

    ip link set eth0 mtu 1196
    

    (これは一時的なものであることに注意してください)

0
törzsmókus