• 締切済み
  • すぐに回答を!

windowsでSYN/ACKを返すプログラム

以下の現象が発生して、大変困っております。 <現象> クライアントからhttpsアクセスをしようとして、 ブラウザに「ページが表示できません」エラーとなることがある。 <調査状況> クライアント、OS上でWireSharkを仕掛けて、TCPの通信をキャッチしたところ、 問題が発生した通信は「SYN」がOSまでは来ているが、 「SYN/ACK」が返ってきていない。 <環境> サーバ:windows2003server,Apache クライアントOS:WindowsXP <質問内容> クライアントからの「SYN」要求に対して、「SYN/ACK」を返すのは、具体的に何が返しているのでしょうか。 (windowsのソケットプログラム?) また、その調査方法があれば教えて頂けないでしょうか。 よろしくお願い致します。

共感・応援の気持ちを伝えよう!

  • 回答数5
  • 閲覧数4277
  • ありがとう数5

みんなの回答

  • 回答No.5

SYN/ACKは、OSのTCPプロトコル処理プログラムが返送します。 SYNパケットを受信したTCP処理プログラムは、対象ポートを listenしているアプリケーションがいればSYN/ACKを返却し、 誰もlistenしていなければRST/ACKを返却します。 SYN/ACKもRST/ACKも返却されていない場合、Windowsファイアウォールや 市販のパーソナルファイアウォールソフトがパケットを破棄している 可能性が高いと思います。 SYN/ACKの替わりにRST/ACKが返却されているのであれば、 アプリ(Apache)が指定ポートをListenしていない可能性が高いです。 いずれの場合も、OSのネットワーク処理レベルの話であり、 Apacheに着信は通知されません。 Apacheの着信処理が動作する前になんらかの異常が発生している と思います。)、

共感・感謝の気持ちを伝えよう!

質問者からの補足

回答ありがとうございます。 Windowsファイアウォールは切っていますが、 市販のウィルス対策ソフトは入っております。 ただ、ウィルス対策ソフトオフにした状態で、現象が再現したので、 関連性は少ないと思っております。 今の時点では、RST/ACKが返却されている状況は確認できておりません。 となると、Apacheの可能性は低いということですね。。。

関連するQ&A

  • 3ウェイハンドシェイクの流れを変える方法

    OS「fedora 5」、言語「C」で、ソケットプログラミングを使い、3ウェイハンドシェイクの流れ <3ウェイハンドシェイク> クライアント     サーバ  syn    →→→        ←←← syn/ack  ack    →→→ これを クライアント     サーバ   syn     →→→         ←←←  rst         ←←←  syn syn/ack   →→→         ←←←  ack の流れにしようと考えています。 参考書を読んだり、ソケットプログラムのことについて調べたのですが、お手上げ状態です。 コントロールフラグの変更の仕方はどうやるのでしょうか? また理論上は3ウェイハンドシェイクを変えることきているのですが、実際は流れ自体変える事は不可能なことなのでしょうか?

  • httpsのページがIE 7で表示できません

    httpsのページがIE 7で表示できません。 表示できないページは、apache version 2.2系で自分で建てたサーバーです。 オレオレ証明書に使ったopensslのversionは0.9.8e, private keyの鍵長は、 1024でも2048でもだめでした。 また、mozilla firefox 3.0では同様に証明書の警告が出ますが、 例外設定をすることで表示されることを確認しています。 IE 7の現象としては、 "この Web サイトのセキュリティ証明書には問題があります。" - (A) と警告が出て、閲覧を続行すると "Internet Explorer ではこのページは表示できません" - (B) といわれます。 このとき、wiresharkでパケットのダンプを見てみると、 (A), (B)の通信が両方とも以下のようなシーケンスになっていました。 1, client -> server : tcp syn 2, server -> client : syn, ack 3, client -> server : syn 4, client -> server : client hello 5, server -> client : server hello, change cipher spec, Encrypted Handshake message 6, client -> server : change cipher spec, encrypted handshake message 7, client -> server : FIN ACK 8, server -> client : ACK 9, server -> client : encrypted alert 10, server -> client : FIN ACK 11, client -> server : RST ACK [ client: IE 7 ], [ server: apache22 ] 7の段階でIEからFIN ACKを送っているためページを表示できないのだと思うのですが、 なぜFIN ACKをおくっているのかが分かりません。 問題を解決したいのですが、はまってしまって困っています。 プロトコル・原因の調査方法等々、何か知っていることがありましたらご教授ください。 よろしくお願いいたします。

  • 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 このような順序になっているように思うのですが、これはなぜなのかご教授頂けないでしょうか? どうぞ、よろしくお願い致します。

  • 回答No.4

> 問題のある通信の時だけ、サーバ側でポートが閉じているのかどうか、 > 調査することはできるのでしょうか。 ポートが待ち受け状態になっているかどうかは、コマンドラインから"netstat -a"を実行すればわかります。 ただ、ファイアウォール機能を使っている場合はそちらの影響も考える必要があります。 > といったことがあるのかどうか、疑っているのはいるのですが、 実装については素人なので外しているかもですが、基本的にTCPセッションの確立まではOSの仕事です。 Apacheは確立したセッション上でデータの送受信をやっているだけのはずです。

共感・感謝の気持ちを伝えよう!

質問者からの補足

回答ありがとうございます。 なるほど、netstatですね。 再現テストはできるので、その間のnetstatの状態をログで出力させるようにしてみます。

  • 回答No.3

サーバ側にSYNが届いていてかつサーバがSYN/ACKを返していないのであれば、問題はサーバ側にあると見て良いでしょう。 ポートが閉じているのかはたまた別の問題なのか、今提示されている情報だけでは何ともいえませんが… > その通信が、Apache上のアクセスログには出ていないという状況です。 そもそもTCPのセッションが確立していないので、Apacheのログには何も出力されないと思います。

共感・感謝の気持ちを伝えよう!

質問者からの補足

回答ありがとうございます。 おっしゃるとおり、サーバ側に問題があると思っております。 問題のある通信の時だけ、サーバ側でポートが閉じているのかどうか、 調査することはできるのでしょうか。 >> その通信が、Apache上のアクセスログには出ていないという状況です。 > >そもそもTCPのセッションが確立していないので、Apacheのログには何も出力されないと思います。 OSのソケットをオープンするのは、Apacheのプロセスだと思うので、 OSまで"SYN"は届いていて、Apacheのプロセスに渡せなかったから ソケットをオープンできず、"SYN/ACK"が返らなかった。 といったことがあるのかどうか、疑っているのはいるのですが、 その辺りの調査方法がわからず、暗礁に乗り上げております。。。。

  • 回答No.2

Apacheのアクセスログより、エラーログを調べるべきかと思います。 > httpsアクセスをしようとして、 Windows2003側のポート443開放と、SSLの設定は出来てますか?

共感・感謝の気持ちを伝えよう!

質問者からの補足

ご回答ありがとうございます。 説明不足で申し訳ございません。 error.log、ssl_request.logは調査しておりますが、エラーは検知できておりません。 Windows2003側のポート443開放と、SSLの設定は出来ております。 通常、https通信が出来ておりますが、 1回/1時間程度、「ページが表示されません」と出てしまうことがあります。

  • 回答No.1

"SYN"に対して"SYN/ACK"を返すのは、"SYN"を受信したホストです。 クライアントが"SYN"を送っているのに"SYN/ACK"が返ってこないのであれば、 (1) SYNがサーバに届いているのか (2) サーバはSYN/ACKを返しているのか をまず調べないと始まりません。 サーバ側にWiresharkを仕込むなり「ネットワークモニタ」(2003に標準付属)を追加インストールするなりして調べるのが良いでしょう。 あとは、どこで通信がブロックされているかをしらみつぶしに調べていくことになります。

共感・感謝の気持ちを伝えよう!

質問者からの補足

回答ありがとうございます。 説明不足で申し訳ございません。 サーバ側にWireSharkを仕掛けた結果、 サーバ側のNickまでは"SYN"が届いていることは確認できております。 その通信が、Apache上のアクセスログには出ていないという状況です。

関連するQ&A

  • ソケット通信の送受信遅延-02 その後

    前回のNo.1031658 「ソケット通信の送受信遅延」に追加させてもらいます その後、プロトコルアナライザで現状調査を行い以下の現象を確認しました ◇正常時  サーバがメッセージ送信  TCPヘッダ内フラグ ACK:1, PSH:1 + 送信データあり ↓  0.2msec前後で クライアントが 返信  TCPヘッダ内フラグ ACK:1, PSH:1 + 返信データあり ↓  10msecで サーバが送信  TCPヘッダ内フラグ ACK:1, PSH:1 + 送信データあり ↓  0.2msec前後で クライアントが 返信  TCPヘッダ内フラグ ACK:1, PSH:1 + 返信データあり ↓          以下繰り返り ◇不具合時  サーバがメッセージ送信  TCPヘッダ内フラグ ACK:1, PSH:1 + 送信データあり ↓  0.2msec前後で クライアントが 返信  TCPヘッダ内フラグ ACK:1, PSH:1 + 返信データあり ↓  10msecで サーバが送信  TCPヘッダ内フラグ ACK:1, PSH:1 + 送信データあり ↓  約130msec前後で クライアントが 返信  TCPヘッダ内フラグ ACK:1, PSH:0 + 返信データなし ↓  約250msec前後で クライアントが 返信  TCPヘッダ内フラグ ACK:1, PSH:1 + 返信データあり ↓ といった状況です どう解釈すれば良いのでしょうか 遅延の原因はソケットなのかそれ以外なのでしょうか?是非アドバイスをおねがいします。

  • TCP/IP ACKについて

    初めて質問させて頂きます。 現在WinpCapを使ってTCPの通信プログラムを作成しています。 単純にパケットの受信や送信は出来たので、ローカルサーバーに接続出来るか試しているのですが、通信が確立しません。 状況としては、こちらからSYN = 1でサーバーに信号を送ると、サーバーから返事が来ます。 サーバーの返事を待ってACK = 1でサーバーに返事をするのですが、そのときの状態をWiresharkで確認すると、ACKの番号が2067011292等と表示されて通信が確立しません。 ACKの値が異常なのは判りますが、この数値はどこから来るのか、又対処方法などが有りましたら教えてください。 環境はVC2003、WInXP/Win7です。

  • 3ウェイハンドシェイクについて

    TCP通信を行う場合、3ウェイハンドシェイクでパイプをつくるようですが、その始め(通信の始め)にSYNを送り、その返信にACKを返す仕組みになっていると思います。そのSYNを送るときに、MAC、IP、TCPヘッダーをつけたパケットを送ると思うのですが、アプリが作ったデータもまた送るのでしょうか?通信できるかどうかを確かめるだけなら最初の通信はデータが必要ないと思うのですが・・・。また、データをつけないパケットなども送ることができるのか(フォーマットに合わないような気が・・・)どうかもあわせてお願いします。

  • ノートン

    ノートンのログで「無効な接続上の TCP 非 SYN/非 ACK パケット。パケットを破棄しました」って出るのですが、どういう意味ですか?

  • C言語でTCPの3way handshake

    (C言語)Linuxのpacket socket(socket(AF?PACKET, SOCK_DGRAM, htons(ETH_P_IP))) を使ってTCPの3way handshakeをOSのプロトコルスタックに頼らず自力で挑戦しています。 RFCやほかの技術本をよんでIPヘッダやTCPヘッダの実装は一応できたのですが、肝心のsynパケットを送った後のackパケットが返ってきません。 wiresharkでは問題なくsynパケットと認識できているのですが、きっとどこかに不備があるはずです。 そこでC, C++ Javaでもいいのでこのプログラムの実装例が載っているサイトなどを教えてください。(英語でもかまいません)

  • 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が省略されてしまうのか原因が知りたいです。また、自分の認識が間違っている場合のご指摘等頂ければと思います。 つたない文章で申し訳ありませんがご存知の方がいらっしゃいましたら教えて下さい。

  • TCPヘッダのヘッダ長について

    誰か知っていましたら御教示ください。 TCPヘッダのヘッダ長は,通常5または6を使用するものだと考えてました 7を使用するのは,どのような場合でしょうか? なぜこのような質問するかは,以下のことをおこなって専用制御装置とPCでTCP/IPの通信が出来なくなっためです。 (1)PC側のOSを winNT→2Kへ変えたところ専用制御装置との通信断となりました。 (2)イーサアナライザで解析したらPCからのSYN送信にてTCPヘッダにおけるヘッダ長がNTの時は,6(24バイト)なのにwin2Kでは,7(28バイト)になった (3)専用制御装置側はTCPヘッダのヘッダ長7は,エラーと判定し通信しない設計になってました (4)PCのアプリはwinsockの単なるソケット通信 そのため,TCPヘッダを書き換えることはできません (5)おそらくOSがwin2Kになったことが原因だと思います。 win2KでwinNTの時のように SYN送信でTCPヘッダのヘッダ長を6にする方法は,あるのでしょうか? 大変恐縮ですが誰か御回答ください。

  • windowsのソフトの動作が不安定になる

    現在とあるwindowsのソフトで動作が不安定になる現象が発生しています。 このソフトというのは、インターネット上に繋がるクライアント端末100台程度と接続しているサーバソフトです。 症状は、起動してから1~2日程度経過すると、100台のクライアント端末と一斉にTCP通信ができなくなる現象です。 現在復旧作業では、このソフトを強制終了して再度ソフトのみ起動すると正常に戻ります。 このソフトの作者さんと連絡をとって現状を報告しているのですが、 ”まだ、よくわからない、もしかしたらwindows10を使用していることで、今までのXPや7では起きなかった現象が出てきているのかもしれない” このような回答でした。 実際の運用現場の方でも解決に向けた調査を行っていきたいと思っているのですが、効果的な調査方法などご教示頂きますよう、宜しくお願い致します。

  • パケットキャプチャについて

    パケットキャプチャについて wiresharkでパケットキャプチャをやっております。tcpでsynのパケットのみを収集したいのですが、現在では、 (1)ファイルの読み込み (2)フィルタの条件でtcp.flag.fin == 0 and tcp.fla.syn ==1 and tcp.flg.ack == 0 と入れフィルタリング。 (3)結果のファイルを保存 となって大変時間がかかります。cuiでコマンドライン上で一発ですませられる方法はありませんか?