- 締切済み
3wayハンドシェイクによるSYN+ACKがNG
■接続状況 <クライアント(1)>──<L3SW(2)>──<LB(3)>──<VPN装置(4)>──~~──> ─>──~~──<FTPサーバ(Solaris)(5)> ■環境 (1):Linux(red hat v5.6) (2):Catalyst L3SW (3):LB(ロードバランサー:NAT変換含む) (4):VPN装置 (5):対向先のFTPサーバ(Solaris) ■業務接続状況 5分周期のバッチで動いている。 クライアント(1)⇒対向先(5)のFTPサーバに対して、FTP接続をしており ファイルのrename等を実施している。(TCP接続) ■障害状況 1ヶ月に2,3回の割合で、クライアントSVから対向先へのFTP接続において FTPエラーが発生している。 ■調査状況 <各キャプチャ設定状況> (1)クライアントSVにて、tcpdump取得、I/F調査の観点でNIC周り調査 (2)L3SWに対しては、ミラーポートキャプチャーをしかけ、キャプチャを採取 (3)LBに対しても、対象IPアドレス、ポートを絞ってネットワークキャプチャを採取 (4)VPNに対しても、対象IPアドレス、ポートを絞ってネットワークキャプチャを採取 FTPエラー時のパケットキャプチャを見ると、3Wayハンドシェイクにおける 対向先(5)からのSYN+ACKがクライアントSV(1)に届いていない状況が判明。 クライアントSVからのSYNに対して、対抗先のFTPサーバからの応答で SYN+ACKがL3SW(2)から出力している(届いている)ところまでは確認済み。 途中経路のLB、VPN含め、パケットドロップ等のエラーカウントアップは されていないのも確認。 肝心のクライアントSVのNICドライバー層を確認するもパケットドロップも カウントしていない為、OSとしては、受け取っていない状況。 FTPエラー時のパケットを見ると、必ずクライアントSV側で5万台の 特定ソースポートで接続するときに限って、SYN+ACKが届いていないことが分かった。 他のPort取得時は正常にFTP処理されている。 ただし、OSやNW専門部署に確認するも特定Portのみ、3Wayハンドシェイクが 確立しないような設定や事例もないの見解を聞いており、手詰まり状態となっている。 特定のPortに関しては、クライアントSVのLinux(OS)が自動で採番できる Port範囲からrandomで取得しているPort番号なのは分かっている。 また、その特定Port番号に関して、アプリ観点等で固定のPort指定や、 エラー発生前に違うプロセスが掴んでしまっているような 競合もとくに見受けられなかった。(定期的に取っているnetstatコマンドより) 似たような事象に陥った方で、何か手がかりになりそうなヒントがあれば ご教授いただけると助かります。
- wata0916
- お礼率100% (1/1)
- その他([技術者向] コンピューター)
- 回答数1
- ありがとう数2
- みんなの回答 (1)
- 専門家の回答
みんなの回答
- hanabutako
- ベストアンサー率54% (492/895)
"RedHat syn ack failure"で検索して一番最初にこういうのが出てきましたが... https://access.redhat.com/solutions/304073 自分はRedHatのサブスクリプションを持っていないので、詳細は見られませんが。 その現象が起きるのはRHEL 5.xからつないだ時だけとかだったりすると、RHELのバグという線が濃厚だと思います。
関連するQ&A
- windowsでSYN/ACKを返すプログラム
以下の現象が発生して、大変困っております。 <現象> クライアントからhttpsアクセスをしようとして、 ブラウザに「ページが表示できません」エラーとなることがある。 <調査状況> クライアント、OS上でWireSharkを仕掛けて、TCPの通信をキャッチしたところ、 問題が発生した通信は「SYN」がOSまでは来ているが、 「SYN/ACK」が返ってきていない。 <環境> サーバ:windows2003server,Apache クライアントOS:WindowsXP <質問内容> クライアントからの「SYN」要求に対して、「SYN/ACK」を返すのは、具体的に何が返しているのでしょうか。 (windowsのソケットプログラム?) また、その調査方法があれば教えて頂けないでしょうか。 よろしくお願い致します。
- 締切済み
- ネットワーク
- TCPのsynとかっていつ・何回位するのでしょうか
ネットワークの勉強中の中年です。 入門編のTCP/IPですが、コネクション確立(syn→ack/syn→syn)などは 普通に手動で作業をする場合、いつ、何回位されるのでしょうか。 たとえばftpなどですが、 もちろん最初にクライアントからサーバーに接続する際にはとは思うのですか、 パスワードを送るたび、ファイルを送受信するたびに行うものなのでしょうか。 また、finを送るのは、byeでftpを閉じる時でしょうか。 パスワードの送信後とか、ファイルのやり取り後といったタイミングで 発生するのでしょうか。 それともパケットトレースで見るように1秒間に何十回というように されるものなのでしょうか。 挙動についていろいろ資料等があるのですが、 実際に使っているイメージではいつ何をしているかわからず… よろしくお願いいたします。
- ベストアンサー
- その他([技術者向] コンピューター)
- TCP/IP ACKについて
初めて質問させて頂きます。 現在WinpCapを使ってTCPの通信プログラムを作成しています。 単純にパケットの受信や送信は出来たので、ローカルサーバーに接続出来るか試しているのですが、通信が確立しません。 状況としては、こちらからSYN = 1でサーバーに信号を送ると、サーバーから返事が来ます。 サーバーの返事を待ってACK = 1でサーバーに返事をするのですが、そのときの状態をWiresharkで確認すると、ACKの番号が2067011292等と表示されて通信が確立しません。 ACKの値が異常なのは判りますが、この数値はどこから来るのか、又対処方法などが有りましたら教えてください。 環境はVC2003、WInXP/Win7です。
- 締切済み
- その他(インターネット接続・通信)
- Cisco VPN Client でパケットが破棄されてしまう
Cisco VPN Client でパケットが破棄されてしまう Cisco VPN Client を使って、自宅のCiscoルータ(Cisco 1812J)にVPN接続しようとしています。ルータの設定を完了し、インターネットから自宅ルータへVPN(IPsec)を張ることには成功したのですが、LAN上のPCにアクセスすることができません。 ・LAN上のホストへPing:OK ・DNSドメイン名解決:OK ・LAN上のホストへのHTTP接続:NG(タイムアウト) 気になるのが、Wiresharkで見たところ、HTTP接続しようとすると、SYN要求に対し相手のホストからちゃんとSYN,ACKが返えってきているのにも関わらず、それを無視してSYNを投げ続けている事が確認できました。さらに、Cisco VPN Client の「統計情報」を見るとパケットの「破棄」が異様にカウントアップしている事も確認できました。 これらの点から、Cisco VPN Clientソフトウェアが通信先からのパケットを破棄してしまっているのが原因ではないかと考えています。しかしその解決法がわかりません。 環境はWindows XP SP3 Professional + Cisco VPN Client ver5.0.06.0160 です(4.8でも試しましたがNG)。Windowsファイアーウォールは無効にしています。市販のFirewallソフトも入っていません。 よろしくお願いします。
- 締切済み
- ネットワーク
- FIN,ACKとACKについて
はじめまして。5月よりTCPソケット通信を勉強しているものです。 クライアントとサーバーのプログラムを作り試行錯誤しながら動かしているのですが一つ不思議な現象が起きたので質問させて頂きます。 処理が終わり、通信を切断する時なのですが、ソケット通信に関連する書籍やWebページを見ていると接続を切断するときにFIN,ACKを送信して相手側がACKを送信し、FIN,ACKを送信して最後にACKを送信するとなっています。図にすると以下のような感じでしょうか。 PCA PCB FIN,ACK送信 → FIN,ACK受信 ACK受信 → ACK送信 FIN,ACK受信 → FIN,ACK送信 ACK送信 → ACK受信 この手順でPCA,PCBともに切断されるとあるのですが、自分が作ったプログラムを実行させて、etherealでパケットをモニタリングすると以下のような状態で終わってしまいます。 PCA PCB FIN,ACK送信 → FIN,ACK受信 FIN,ACK受信 → FIN,ACK送信 ACK送信 → ACK受信 PCAからのFIN,ACK受信に対してのACKの送信が省略されて、いきなりFIN,ACKを送信してしまいます。その後PCAからはACKが返されて終了となります。 プログラム的には希望通り動作しているので問題は無いのですが、なぜ途中のACKが省略されてしまうのか原因が知りたいです。また、自分の認識が間違っている場合のご指摘等頂ければと思います。 つたない文章で申し訳ありませんがご存知の方がいらっしゃいましたら教えて下さい。
- 締切済み
- ネットワーク
- ftp遅延
Windows2003サーバーの標準ftpからJP1/ftpサーバーへ、VPNを介して最大2MB程度のファイルを100~200個mput転送しています。2,3ヶ月に1回程度、転送遅延が発生します。Wiresharkでパケットキャプチャして調査したところJP1/FTPからのウインドウサイズが通常時32768バイトから1024バイトになっていました。さらに1024になった後、ftpクライアント側がACK受信後に5秒間waitしてから次のパケットを送信するような動きになっています。計ったように5秒ぴったりです。Windowsのftpクライアントがデータ転送を遅らせるような設定、仕様はないとの認識ですが何が原因として考えられるでしょうか?またどのような調査が有効でしょうか?ちなみにftpクライアント側のPCにはVPNクライアントやアンチウィルスソフトは稼動していません。
- 締切済み
- ネットワーク
- WiresharkのFlow Graph
現在WiresharkのFlow Graphという機能を使用して、クライアント端末がサーバー端末へのTCP通信での3ウェイハンドシェイクのパケットやりとりを観測したいと思っています。 次のようなパケットをモニターしました。 |Time | 192.168.1.111 | | | | 192.168.1.222 | |6.402 | PSH, ACK - Len: 1212 |Seq = 1 Ack = 1 | |(6057) ------------------> (5000) | |6.606 | PSH, ACK - Len: 1212 |Seq = 1 Ack = 1 | |(6057) ------------------> (5000) | |6.835 | PSH, ACK - Len: 1212 |Seq = 1 Ack = 1213 | |(6057) <------------------ (5000) | |7.039 | ACK | |Seq = 1213 Ack = 1213 | |(6057) ------------------> (5000) | |7.150 | ACK | |Seq = 1213 Ack = 1213 このパケットのやりとりを観ていて思ったのですが、TCP通信は3ウェイハンドシェイクは SYN--->SYN ACK---> ACK という順序でのパケットのやりとりをクライアントとサーバー間で行うと思っていたのですが、 PSH, ACK ----> PSH, ACK ----> ACK ----> ACK このような順序になっているように思うのですが、これはなぜなのかご教授頂けないでしょうか? どうぞ、よろしくお願い致します。
- ベストアンサー
- ネットワーク
- パケットキャプチャについて
パケットキャプチャについて wiresharkでパケットキャプチャをやっております。tcpでsynのパケットのみを収集したいのですが、現在では、 (1)ファイルの読み込み (2)フィルタの条件でtcp.flag.fin == 0 and tcp.fla.syn ==1 and tcp.flg.ack == 0 と入れフィルタリング。 (3)結果のファイルを保存 となって大変時間がかかります。cuiでコマンドライン上で一発ですませられる方法はありませんか?
- ベストアンサー
- ネットワーク
- HTTP GET直後のFIN,ACKについて
ある特定のサイトをWebアクセスした際のWiresharkトレースを解析しています。 そのWebサイトにはTwitterのAPIが埋め込まれていて、Twitterのアイコンを取得するためにJPGファイルを取得しているTCPセッションがあります。 3WAYハンドシェイクの後、クライアントはHTTP GETでJPGファイルを要求しているのですが、直後にFIN,ACKフラグを伴うパケットを送出しています。 クライアントは自らHTTP GETしておきながら、JPGファイルを受け取る前にTCPセッションを終了しようとするのは理解しがたいと思っています。 このようにHTTP GET直後にFIN,ACKフラグをつけるような挙動をみせるのはどのような状況が予想されるでしょうか?
- 締切済み
- その他([技術者向] コンピューター)
お礼
ありがとうございます。 会社に行かないと、サブスクリプションが使えないので、さっそく、週明け確認させていただきます。 自社内のOSサポートからは特に過去事例でないといわれていたので鵜呑みにしてしまいました。 取り急ぎ、お礼まで。