「DAブラックホール」と「KONDERU-NDA」を作っているというお話
DAブラックホール1.7.29にアップデートした。
当然のことに、なにを言っているのかわからない、という向きもあるかもしれないが、電話回線をIP化するとDAブラックホール(ISDN用)が使えなくなるという「問題」は、増えている。
あるとき、DAブラックホール(1.3～1.7)をISDN回線で使うと、リザルトにx063などの「サービス利用不可クラス」ばかり返るようになり、意図した解析結果が得られない。
TAにNEC Atermシリーズを用いている場合は、リザルトに2063（自分側の局交換機）が返る。
リザルトが返るということで、ローカルインターフェースの切断・解放完了が行われていることがわかる。（すなわち機器の故障ではない）
解析タイムは100～300msと短く、局交換機（LN)が返したにしては、タイムが速すぎる。
念のためDAブラックホールのメイン画面のスクリーンショットとデバイス試験データの作成をユーザーにお願いしている。これらに異常がない場合は、回線そのものに原因があると考える。
実例として最も多いのが、「事業所をひかりIP化した」というものである。
導入業者の事前説明で「ISDNがそのまま使える」と言われたから、というのもポイントになっている。
もちろん業者さんの説明不足である。IP用のゲートウェイ装置を間に入れて「ISDN機器の多くがそのまま使える」ということではあろうが、G4FAXやISDNデータ通信は 2017年現在、NTTのISDN網（PSTN/SS7）には抜けない。
例外的に支社のIP網からVPNを介して本社のISDN回線を使っているという方は知っているが、一般的とはいえない。
おそらくは請負契約書に「G4FAXやISDNデータ通信は除く」と免責事項が書かれているはずだから、工事したあとはどうにもならない。
あたらしくINSの回線を引きなおすか、他の回線種に変更せざるをえない。
ISDN機器とIP網の間に入れるゲートウェイ装置が、サービス利用不可クラスの生成源を 2（LN・ローカルユーザ収容公衆網）ではなく 1（LPN・ローカルユーザ収容私設網）で返してくれると わかりやすくなるんだけどね。
偶然重なったのかもしれないけれど、ここ数日で この「Windows ファイアウォールによりライセンス認証が行えない問題」が2件・サポート報告で上程された。
たまーに、ある。この事象。
オンラインによるライセンス認証機能を持つDAブラックホール1.5～1.7で、Windows ファイアウォールによりアプリケーションの通信がブロックされているときには、ライセンス認証が有効にならない、という現象が起きる。
まぁ、当然なんだけどね。
このときDAブラックホールは、「ライセンス認証が行えませんでした。」というクリティカルメッセージボックスを表示する。
厄介なのは、DAブラックホールにとっては「OS」が「正常に遮断」しているので、なんらOSのエラーを拾えないまま、しかし認証結果だけは返ってこないので、自動的な障害判定ができないことである。（ユーザーに対して、こういった原因で処理が行えませんでした、というサジェッションができない）
さらに厄介なことに、Windows ファイアウォール で レシーブだけカットするような設定であれば、当社サーバーは「正常に処理を行った」というログを残していくので、問い合せを受けた際の異常の検出に時間を要する。（細かく調べればわかるのだけど）
サポートに問い合わせると、回答フローの最初のほうで
と案内されるので、その時点でだいたいの人はピンとくる。（FWを設定するぐらいのユーザーであれば特に）
気がついてしまえば
コントロールパネル→Windows ファイアウォール→Windows ファイアウォールを介したアプリまたは機能を許可
で、DAブラックホールを許可してしまえばいいだけなんだけどね。
だけど、アプリケーション単位のFW設定なんて、安定して長いこと使ってるPCなら、設定していることを忘れることあるもので、そうなるとユーザーサポートへの問い合わせまでに、わりと長時間、ドはまりしてしまう方もいるかもしれない。
初心者ほど「ぱっ」と聞いちゃうものだが、もしFW設定を自らするような上級者であれば、問い合せまでに時間を要することもあるだろう。
特定プロトコルだけの閉塞または開放忘れを、クライアント側のアプリケーションだけで自動判定するのは荷が勝ちすぎているかもしれないが、これを機に、何か考えてみようと思う。