Avast! の Web シールドを一時停止しても WebSocket で接続できない
最近 WebSocket サーバをGo言語の勉強を兼ねて作っているのだが、友人の環境で接続に失敗してしまう問題が起こり、それの解決策がわからず微妙に悩んでいたが、タイトルに書いてあるとおり Avast! が原因だということがわかった。
WebSocket の情報がまだ少ないと思って検索してなかったが、avast websocket で検索すると思いっきりそれに関する情報が出てくるではないか。
この一件で個人的にはもう無料で対策したいなら Microsoft Security Essentials、最新のウィルスからも迅速に保護されたいなら有料の有名どころを使えばいいじゃないと内心思ってしまった。
カスペルスキー系はここに書いてあるトラブルシューティングで回避方法が書かれているので手動設定しないとダメかも。
以下は発見までの経緯。
繋がらないとはいってもハンドシェイクの段階で先に進まなくなっているようで、接続のイベントが発生することもなく、サーバ側で netstat するとクライアント情報としては現れるという状態だったので、全くアクセスできていないわけではなかった。
クライアント側の問題だと思い原因を友人に調べてもらっている途中、Proxomitron を経由すると接続に成功することがわかった。それでクライアント側の問題である可能性が濃厚だなーは思ったのだが、友人が普段使用している Avast! も Zone Alarm も一時停止してもらったものの結局繋がらなかった。
更に検索してサンプルとして WebSocket サーバを立てているようなページを見つけて試してもらってもやはり Proxomitron なしではダメだった。
その後、どうも友人宅の別の PC でも同じ問題が起こることがわかった。そしてセキュリティ環境も一緒にしてあるという話からやはりその周辺に原因があるだろうと考えてもう一度セキュリティソフト周辺を疑いなおしてもらったら、Avast! の Web シールドを一時停止ではなく終了することであっけなく成功してしまった。
Avast! の一時停止はあくまで安全性のチェックを一時的に停止するだけで処理の途中に挟まったままで、想定外の通信の妨害をしてしまうような事態を回避するためには使えなかったようだ。
一時停止ではなく、終了。ちぃ覚えた。
更に調べていくうちにポート80番で WebSocket の接続を行なおうとするとその問題に引っかかってしまうことがわかり、最初にポート10080番への接続を試行して、それがダメだったらポート80番に接続しに行くようにして対処した（ただ本当にこれで上手く行くと言い切るには調査不足感が否めない）。
そもそもポート80番で HTTP と WebSocket を共有しているのはポート80番とかポート443番以外を蹴ってしまうファイアウォール突破のための対策なので、今回のようなケースではなく本当にポート番号基準でブロックされるなら接続自体に失敗するはずで、接続して無応答になるよりは失敗の検出が速いはず、という推測。
でもポート80番使わなければ成功するってことはつまりそれって保護されてないんじゃないの。
大丈夫なのそれ。
WebSocket の情報がまだ少ないと思って検索してなかったが、avast websocket で検索すると思いっきりそれに関する情報が出てくるではないか。
この一件で個人的にはもう無料で対策したいなら Microsoft Security Essentials、最新のウィルスからも迅速に保護されたいなら有料の有名どころを使えばいいじゃないと内心思ってしまった。
カスペルスキー系はここに書いてあるトラブルシューティングで回避方法が書かれているので手動設定しないとダメかも。
以下は発見までの経緯。
繋がらないとはいってもハンドシェイクの段階で先に進まなくなっているようで、接続のイベントが発生することもなく、サーバ側で netstat するとクライアント情報としては現れるという状態だったので、全くアクセスできていないわけではなかった。
クライアント側の問題だと思い原因を友人に調べてもらっている途中、Proxomitron を経由すると接続に成功することがわかった。それでクライアント側の問題である可能性が濃厚だなーは思ったのだが、友人が普段使用している Avast! も Zone Alarm も一時停止してもらったものの結局繋がらなかった。
更に検索してサンプルとして WebSocket サーバを立てているようなページを見つけて試してもらってもやはり Proxomitron なしではダメだった。
その後、どうも友人宅の別の PC でも同じ問題が起こることがわかった。そしてセキュリティ環境も一緒にしてあるという話からやはりその周辺に原因があるだろうと考えてもう一度セキュリティソフト周辺を疑いなおしてもらったら、Avast! の Web シールドを一時停止ではなく終了することであっけなく成功してしまった。
Avast! の一時停止はあくまで安全性のチェックを一時的に停止するだけで処理の途中に挟まったままで、想定外の通信の妨害をしてしまうような事態を回避するためには使えなかったようだ。
一時停止ではなく、終了。ちぃ覚えた。
更に調べていくうちにポート80番で WebSocket の接続を行なおうとするとその問題に引っかかってしまうことがわかり、最初にポート10080番への接続を試行して、それがダメだったらポート80番に接続しに行くようにして対処した（ただ本当にこれで上手く行くと言い切るには調査不足感が否めない）。
そもそもポート80番で HTTP と WebSocket を共有しているのはポート80番とかポート443番以外を蹴ってしまうファイアウォール突破のための対策なので、今回のようなケースではなく本当にポート番号基準でブロックされるなら接続自体に失敗するはずで、接続して無応答になるよりは失敗の検出が速いはず、という推測。
でもポート80番使わなければ成功するってことはつまりそれって保護されてないんじゃないの。
大丈夫なのそれ。