それから、以下の記述は10年ほど前に契約した当時の、住友電工のCTUにのみ該当するようで、クレーム後いったん予防交換といって工事屋さんが置いていった日立のCTUでは、デフォルトのパケットフィルタ設定は入っていないようでした。
CTUにつないでいたBuffaloのWi-Fiルータはフレッツ光のPPPoEリンク設定がデフォルトで入っていたようで、ほとんど何も考えずにISPのログイン設定するだけで終わったので、フレッツな人はみんなネクストに契約切り替えたほうがいいと思います。うちは集合住宅で光ケーブルが部屋まできていないので上限100Mbpsのままですけど、いままでがひどすぎたので劇的な改善であります。
工事料金無料、契約は「隼」(最大1Gbps)ではないので料金同じ、2年縛り割引もそのまま引き継ぐということで、特にこちらから申込書を書くこともなく、ただ契約変更通知が郵送されてきただけでした。工事屋さんは管理人室内の終端ボックスの配線付け替えとCTUの引取り、データリンクの確認と伝票の印刷だけしてお帰りになられました。簡単。
ひかり電話とかフレッツ・テレビ(スカパーHDとかがフレッツIPv6網で観られる)を契約するとそういう機能つきのNTTご提供ルータに交換するみたいですが、うちはシンプルにやっております。
自宅はNTT西のフレッツ光を使っていますが、どうも最近つながらない、よく切れるという症状で悩んでおりました。
困るのは、SSH接続がブツブツ切れることでして、これではサーバのメンテナンスもできません。コンパイル途中で切れるとか、インデックス作成中に切れるとかすると、shellが子プロセスもろとも落ちるので、ちっとも作業が進みません。
NTT西に電話して、機器や配線の電気的な点検を依頼するとか、週末なので問い合わせフォームしかなかったけれど某ISPのカスタマサポートに通信制限状況の問い合わせを投げてみるとかしてみましたが、そうしている間、瞬間的にIPアドレス重複のメッセージが現れたのをみつけて、どうもDHCPサーバになっているCTU(NTT用語で要するにPPPoEルータ)が怪しいと思い、設定を見なおしてみました。
まず、自分のMacのIPアドレスが使われるのはたまらないので、MACアドレス指定でスタティックなIPアドレス設定に変更。
そのあと、ログをみるわけですが、「不正アクセスログ」という画面ぐらいしかまともに時系列のログがないので開いてみたところ、「つながらない」と思っていた相手への接続をCTUが切断していました。現員は「SPIによる破棄」。へえ、そんな立派なものがと思いつつ、「なんで捨てるんだよ」という怒りにも似たやるせなさが。
検索すると、CTUのWAN側IPv4アドレスが「123から125の間で始まる場合」、つまり上から8bitが123-125のブロックの場合、一部のIPアドレスに対するパケット送信をSPIが破棄するという問題がある、という古い記事(しばらく前にファームウェアの更新があったけれど、それより古いという意味)がいくつか見つかり、「ファイアーウォールをオフにしてください」と書かれているサイトが複数ありました。
CTUの設定画面上、たしかにオフが誰でもわかる選択項目だけれど、それは乱暴ではないかと思いつつ。
CTUログイン直後の画面左にファイアウォール設定項目がある |
とはいえ、「制限なし」は乱暴ではないかと思う。SPIは「詳細設定」のなか |
ということで、SYN Flooding対策にはSPIほしい気もするけどどうなんだと思いながらも、現実にいまつながらない相手があり、家人のスマホらしきIPアドレスでも破棄されているので、これは手元のMacだけの問題ではないと思い、SPIを停止して様子をみることにしました。
ただ、SPIを止めるためには、「ファイアウォール詳細設定」という別立ての項目を設定して、とパケットフィルタリングのルールを自分で書く画面と同じところに入らなければならないわけです。
「詳細設定」画面の上にSPIの項目があるけれど、「編集」を押さなければならない仕様 |
ここでようやく選択できる。OKで前の画面に戻る |
ルールは先頭(若い番号)から順に評価されます。なので、「全部閉じて開くものを指定する」か「全部開いておき、閉じるものを指定する」か、どちらかを最初に決めなければなりません。
それで、後者を選んだ場合、デフォルトは「全部閉じている」になります。よって、先頭に、全てを「許可」するルールを置かなければなりません。ルール番号は1がいいでしょうか。「IPバージョン」に「IPv4・IPv6」を選び、「プロトコル」を「すべてのプロトコル」に変更するのを忘れないでください。初期値は「IPv6」「TCP」です。
そのあと、Windowsのファイル共有関係の137-139と445を書いておけば十分なようです。念のため、以下の図では53/TCPと53/UDP(DNS)を拒否するルールを書いていますが、「不正アクセスログ」をみると、特にルールを書かなくても「NATによる破棄」を理由として、たいていの試みは失敗するような動作をするようです。少なくともWell Knownなポートに関してはSYNの時点で捨ててくれますし、そうでない怪しい443(HTTPS)からの接続とかは、宛先ポートによらずESTABLISHEDのところで捨ててくれます。したがって、ルールがなくてもそれなりにうまく制限してくれるのかもしれない。
しかし、443や53から接続する攻撃があるのに驚きました。ルールの書き間違いを期待しているんでしょうか。あるいは、送信元が80や443だと通してしまう誤ったフィルタが設定された商品があるんでしょうか。
特定のポートを制限するなら、先頭に「全部通過する」ルールを置く必要があるので注意 |
この画面には「戻る」ボタンしかありませんが、変更内容はメモリに保持されています。これを保存するには、「戻る」で現れたトップ画面の画面左にある「設定反映」ボタンを押さなければなりません。すると、いったん確認画面を経由したあと、再起動が必要な選択をしたから再起動してくださいというメッセージとともに、「再起動」ボタンが配置された画面に遷移します。再起動は1分ぐらいだと思います。ときどき適当なサイトにpingでも打ちながら待っていると、そのうち反応があります。いつまでたってもunreachableな場合は、おそらく1番ルールの「最初にすべての通信を許可する」ときに「すべてのプロトコル」を選ぶのを忘れていて、ICMPが通らなくなっています。
あとはお好みで調整してください。再起動の時点で「不正アクセスログ」を開くと、早くも多数の怪しいパケットを捨てたことがみてとれます。
ひとまずこれで様子見です。