Unboundを有効活用する その2 （FreeBSD 13.3R、2024/04/07） [FreeBSD]
そういえば、やりたいことを説明していませんでした。
やりたいことはUnboundを自宅内のキャッシュDNSサーバとして稼働させることです。FreeBSDサーバ機自身だけでなく、DHCP等で家庭内にアドレス配布し、Windows機、スマートホンなどにも使わせるイメージです。
ただ、以前似たようなことをBINDで実装したとき、FreeBSD機の障害や電源OFF時に、家庭内でDNS名前解決ができなくなり、復旧が面倒だったので、今回は一工夫入れます。
至ってシンプルですが、
・キャッシュDNSサーバ（FreeBSD）のフォワーダーはISPのDNSサーバを設定する
・DHCPで配布するDNSサーバは、①FreeBSD Unbound ②ISP DNSサーバとする
こうやることで、FreeBSD障害時でも最低限の名前解決は維持できるようにします。
その3へ続く。
やりたいことはUnboundを自宅内のキャッシュDNSサーバとして稼働させることです。FreeBSDサーバ機自身だけでなく、DHCP等で家庭内にアドレス配布し、Windows機、スマートホンなどにも使わせるイメージです。
ただ、以前似たようなことをBINDで実装したとき、FreeBSD機の障害や電源OFF時に、家庭内でDNS名前解決ができなくなり、復旧が面倒だったので、今回は一工夫入れます。
至ってシンプルですが、
・キャッシュDNSサーバ（FreeBSD）のフォワーダーはISPのDNSサーバを設定する
・DHCPで配布するDNSサーバは、①FreeBSD Unbound ②ISP DNSサーバとする
こうやることで、FreeBSD障害時でも最低限の名前解決は維持できるようにします。
その3へ続く。
Unboundを有効活用する その1 （FreeBSD 13.3R、2024/04/05） [FreeBSD]
うちのFreeBSDのサーバ、CPUはPentium Silver J5040、メモリは16GBでそこそこ良いモノを装備しているんですが、あまり有効に使えてなかったりします。ほぼ常時稼働のNASサーバとしても使っているので（というかこれがほぼメイン）、なんかないですかね？
というわけで、FreeBSD標準添付のUnboudを使って、DNSキャッシュサーバ兼、muninの可視化でもやってみることにしました。
FreeBSDには標準構成にUnboundが含まれており、pkgから導入しなくてもそのまま使うことができます。さすがBSDライセンスですね。標準添付のUnboundは自分自身に対するローカルキャッシュサーバの用途に特化しているようで、rc.confの設定上でも「local_unbound」としてpkg導入のものと区別されています。
ただ、local_unboundに関してはあまり参考ドキュメントがないようで、正直使い方がよく分からない。デフォルトコンフィグがどこにも置かれていない。share/exapmlesのどこかにあるかなと思って探してみたのですが、それそれもなさそう。
賢いFreeBSDのことなので、エラーメッセージで何か教えてくれるだろうと思い、rc.confにlocal_unbound_enable="YES"を書き込んで強制的にサービス開始。と、…/etc/unbound配下に勝手にコンフィグ作って動作してくれました。しかもほぼ完成版で、修正する箇所がなくて困るぐらい。
control.conf
forward.conf
lan-zones.conf
root.key
unbound.conf
ただ、これでめでたしめでたし、といかないのが楽しいところ。名前解決…できませんでした！
resolv.confも修正されており、もともと設定されていたDNSサーバはforward.confにちゃんと移植されていて、コンフィグは問題なさそう。
サービスも立ち上がっていて、127.0.0.1でListen状態だし、はてな？？ 勝手に作成されたコンフィグ本体のunbound.confも特には問題なさそうです。
その2へ続く。
というわけで、FreeBSD標準添付のUnboudを使って、DNSキャッシュサーバ兼、muninの可視化でもやってみることにしました。
FreeBSDには標準構成にUnboundが含まれており、pkgから導入しなくてもそのまま使うことができます。さすがBSDライセンスですね。標準添付のUnboundは自分自身に対するローカルキャッシュサーバの用途に特化しているようで、rc.confの設定上でも「local_unbound」としてpkg導入のものと区別されています。
ただ、local_unboundに関してはあまり参考ドキュメントがないようで、正直使い方がよく分からない。デフォルトコンフィグがどこにも置かれていない。share/exapmlesのどこかにあるかなと思って探してみたのですが、それそれもなさそう。
賢いFreeBSDのことなので、エラーメッセージで何か教えてくれるだろうと思い、rc.confにlocal_unbound_enable="YES"を書き込んで強制的にサービス開始。と、…/etc/unbound配下に勝手にコンフィグ作って動作してくれました。しかもほぼ完成版で、修正する箇所がなくて困るぐらい。
control.conf
forward.conf
lan-zones.conf
root.key
unbound.conf
ただ、これでめでたしめでたし、といかないのが楽しいところ。名前解決…できませんでした！
resolv.confも修正されており、もともと設定されていたDNSサーバはforward.confにちゃんと移植されていて、コンフィグは問題なさそう。
root@MyFreeBSD:/etc # cat /etc/unbound/forward.conf
# This file was generated by local-unbound-setup.
# Modifications will be overwritten.
forward-zone:
name: .
forward-addr: 192.168.x.xサービスも立ち上がっていて、127.0.0.1でListen状態だし、はてな？？ 勝手に作成されたコンフィグ本体のunbound.confも特には問題なさそうです。
root@MyFreeBSD:/etc # cat /etc/unbound/unbound.conf
# This file was generated by local-unbound-setup.
# Modifications will be overwritten.
server:
username: unbound
directory: /var/unbound
chroot: /var/unbound
pidfile: /var/run/local_unbound.pid
auto-trust-anchor-file: /var/unbound/root.keyその2へ続く。
中古のFortigateについて その1（2023/05/23） [ネットワーク機器]
ファイアウォールアプライアンスとして、Juniper SSGにはお世話になったものですが、最近はすっかりFortigate一色ですね。他の選択肢をとるならPaloaltoなんてものもあるようですが。
個人的にFortigateは接点があまりなかったのですが、いざ実際に使ってみたところなかなか面白いですね。基本的に必要とされる機能が、一通り文句ないぐらいの作り込み度合いで実装されています。
Fortigateの便利さに慣れてしまうと、CISCOルータが随分とショボく見えてしまいます。
Fortigateの機能でよく分からなかったもの一つに、ライセンスの定期アクティベーションがあります。一般にUTM機能を利用する場合はシグネチャの「更新」は必要ですが、Fortigateは基本のファイアウォール機能の使用だけでも、定期的にアクティベーションを行うようです。
ファイアウォール機能は基本機能ですし、特別な追加ライセンスを必要とするものではありません。通信環境によっては、インターネットに接続できない完全オフラインで使う場合もありますので、オンラインの定期アクティベーション行為は必須なのか？と疑問に思ってしまいます。
裏を返せば、保守・ライセンス切れの中古Fortigateを買ってまともに使えるのか？ということですね。
私の個人的な調査の結果、結論から言えば
私の調べた限り、UTM系のシグネチャ更新を除けば、オンラインのアクティベーション通信で以下を更新しているようです。
①ISDB（Internet Service Data Base）
②Geo-IP
その2へ続く。
個人的にFortigateは接点があまりなかったのですが、いざ実際に使ってみたところなかなか面白いですね。基本的に必要とされる機能が、一通り文句ないぐらいの作り込み度合いで実装されています。
Fortigateの便利さに慣れてしまうと、CISCOルータが随分とショボく見えてしまいます。
Fortigateの機能でよく分からなかったもの一つに、ライセンスの定期アクティベーションがあります。一般にUTM機能を利用する場合はシグネチャの「更新」は必要ですが、Fortigateは基本のファイアウォール機能の使用だけでも、定期的にアクティベーションを行うようです。
ファイアウォール機能は基本機能ですし、特別な追加ライセンスを必要とするものではありません。通信環境によっては、インターネットに接続できない完全オフラインで使う場合もありますので、オンラインの定期アクティベーション行為は必須なのか？と疑問に思ってしまいます。
裏を返せば、保守・ライセンス切れの中古Fortigateを買ってまともに使えるのか？ということですね。
私の個人的な調査の結果、結論から言えば
問題なく使えるようです
私の調べた限り、UTM系のシグネチャ更新を除けば、オンラインのアクティベーション通信で以下を更新しているようです。
①ISDB（Internet Service Data Base）
②Geo-IP
その2へ続く。
タグ：fortigate
(Galaxy) S Healthの万歩計が使えない その5（2023/04/17） [Android＆スマホ]
えー、はい。実際に歩いて実測しました。
普段は時刻を確認するなどで移動中もちょこちょこ電源ONにしているのですが、今回はスマホの省電力時の挙動を明確にするために、常時電源OFF状態を維持するようにします。
歩数カウントの多数決を取るために、以下の3つを比較することにします。
Google Fitは実質Android標準万歩計になると思われ、スマホ省電力の影響を受けないことや、精度良くカウントアップしてくれることを期待しています。
・Galaxy S Health（Androidアプリ）
・Google Fit（Androidアプリ）
・Xiaomi Smart Band 7（ウェアラブルデバイス）
残念ながら、出発前のカウンタ0の時のスクリーンショットを撮り忘れてしまったのですが、途中と最後の2つのスクリーンショットが以下の通りです。
各スクリーンショットの、上のカウンタがS Health、下のカウンタがGoogle Fitとなります。Xiaomi Smart Band 7は腕時計のため（私の）目視結果のみです。
肝心な出発前のカウンタを取り忘れていますが、ここに載せているスクリーンショットの差分だけでも、Google Fitの約2700歩の増分に対し、S Healthの増分は7歩と、明かな異常が観察できました。
スマホの省電力が影響し、S Healthはきちんと機能していないというのが明白ですね。
一応、最終結果としては、
・Galaxy S Health 1341歩
・Google Fit 6440歩
・Xiaomi Smart Band 7 6941歩
でした。
普段は時刻を確認するなどで移動中もちょこちょこ電源ONにしているのですが、今回はスマホの省電力時の挙動を明確にするために、常時電源OFF状態を維持するようにします。
歩数カウントの多数決を取るために、以下の3つを比較することにします。
Google Fitは実質Android標準万歩計になると思われ、スマホ省電力の影響を受けないことや、精度良くカウントアップしてくれることを期待しています。
・Galaxy S Health（Androidアプリ）
・Google Fit（Androidアプリ）
・Xiaomi Smart Band 7（ウェアラブルデバイス）
残念ながら、出発前のカウンタ0の時のスクリーンショットを撮り忘れてしまったのですが、途中と最後の2つのスクリーンショットが以下の通りです。
各スクリーンショットの、上のカウンタがS Health、下のカウンタがGoogle Fitとなります。Xiaomi Smart Band 7は腕時計のため（私の）目視結果のみです。
肝心な出発前のカウンタを取り忘れていますが、ここに載せているスクリーンショットの差分だけでも、Google Fitの約2700歩の増分に対し、S Healthの増分は7歩と、明かな異常が観察できました。
スマホの省電力が影響し、S Healthはきちんと機能していないというのが明白ですね。
一応、最終結果としては、
・Galaxy S Health 1341歩
・Google Fit 6440歩
・Xiaomi Smart Band 7 6941歩
でした。
タグ：S Health
