nabeの雑記帳

ルーティングテーブル書き換え（route）によるアクセス制御から、unboundによるDNSの一部書き換えに移行したメモ。

• 状況
• 力技で解決していた
• unboundによるDNSの書き換え
  • 確認
  • ルータの設定書き換え
• まとめ
• その後

状況

LAN内のLinuxマシンを、家庭用ルータのポートマッピングを使って外部公開している状況を想定しています。小規模の会社とかでも、こういう設定をされていることがありますね。

この場合、内側のPCから外部公開時のホスト名である「global.my.ip」にアクセスするとグローバルIPを引いてしまいます。そして、PCからルーターの外側IPにアクセスすることになるのですが、NEC等のルータではこの際ポートマッピングが有効にならずアクセス不能となります。*1

ルータのルーティングテーブルを書き換えることができれば色々と解決策はあるのですが、そんな機能を持った機種はまずありません……。*2

力技で解決していた

どうにもならないので、PCを起動するたびに、外部IPを確認して、外部IPにアクセスするときはLinuxサーバ（192.168.1.8）にルーティングするような設定をしていました。

@echo off
' route-add.bat
for /f "usebackq tokens=2 skip=1" %%i in (`nslookup global.my.ip 192.168.1.1 ^| findstr "[0-9]\.[0-9]"`) do set IP=%%i
route add %IP% 192.168.1.8

これで、PCから外部IP向けのパケットがLinuxサーバに向かうので、Linuxサーバ側でNAT処理をします。

MY_LOCAL="192.168.1.2"
MY_GLOBAL=`dig +short global.my.ip`
#---------------------------------------------------------------------------
# Special forward for myself
#---------------------------------------------------------------------------
iptables -t nat -A OUTPUT      -d $MY_GLOBAL -s $MY_LOCAL \
         -j DNAT --to-destination $MY_LOCAL
#---------------------------------------------------------------------------
# Special forward for local network
#---------------------------------------------------------------------------
iptables -t nat -A PREROUTING  -d $MY_GLOBAL -s $MY_LOCAL/24 \
         -j DNAT --to-destination $MY_LOCAL

これで無事アクセスはできるのですが、スマホ等からのアクセスは断絶されたままでした。

unboundによるDNSの書き換え

unboundというDNSキャッシュサーバには、特定のホスト名やドメインだけ、DNSの結果を書き換える機能が付いています。

本当は外部IPでのアクセスがすべてLinuxサーバに転送されるのが理想なのですが、そうも言ってらもないので、この方法で解決を試みました。以下、Debianサーバでの設定例です。

sudo su
apt-get install unbound

/etc/unbound/unbound.conf を編集して以下を追加します。

server:
        interface: 0.0.0.0
        access-control: 127.0.0.1 allow
        access-control: 192.168.0.0/16 allow

続いて /etc/unbound/unbound.conf.d/global.my.ip.conf というファイルを新規作成します。

local-data: "global.my.ip A 192.168.1.8"

作成したら unbound にリロードさせます。

service unbound reload

確認

$ dig @localhost global.my.ip
;; ANSWER SECTION:
global.my.ip.           3600    IN      A       192.168.1.8

ルータの設定書き換え

ルータのDHCPの設定を書き換えて、DNSのプライマリサーバに 192.168.1.8 を指定します。セカンダリは 192.168.1.1 を指定しておくと良いでしょう。

まとめ

NECのルータは性能は悪くないけど、細かい設定ができないのでちょっと面倒ですね。

UPnPタイムアウトを設定できないし（高級機のみ可）。Buffaloのほうがいいのかもしれない。ポート転送が内側に対しても効いた気がするし。

その後 2020/4/15

IPv6化して解決したため、unboundを削除しました。

さていつものラズパイ用DACですが、最新のVolumio2をちょっと入れて試してみました。

• 使い続けた Volumio Ver1
• 外部クロック動作の確認
• 384KHz/32bit再生の確認
  • 768KHz/32bitを設定したら……
• ssh有効化（メモ）
• まとめ

使い続けた Volumio Ver1

昔（といっても2年ぐらい前）は、オーディオ用ディストリビューションと言ってもVolumioぐらいしか認知されてなくて、事実上他に選択肢はありませんでした。

まあ色々と使いにくい点もあったのですが、カスタマイズして使っているうちにちょうどよくなってそのまま使い続けたという。

他のディストリビューションはどうにも肌に合わず、当時Volumio2のβ版は使い勝手が悪くて結局そのままという状況でしたので、一念発起して使ってみることにしました。*1

入れてみるとさすがに完成度が高く、これなら完全に乗り換えても良いですね。

外部クロック動作の確認

msBerryDACはHiFiBerry DAC+ PRO互換ですが、このPRO付きとPROなしはドライバが共通になっています。

この判別はドライバ側で行っていて、音が鳴っていても外部クロックが正しく使われているかはソフトからでは分かりません。ドライバ側で認識方法が狂っていたりすると、外部クロックが使われずに音が再生されたり、狂ったクロック（速度）で音が再生されてしまいます。

これを確実に確認するには、発振器（やクロック）の端子にテスター等を当ててクロックがきちんと動作しているか確認するしかありません。

というわけで、最新のVolumio2で外部クロックの動作を確認しました。ついでに分かったことですが、リサンプリングをオフにしておいても、リサンプルされて48k系列のクロックで再生されているようです。

384KHz/32bit再生の確認

β版当時には存在しなかったアップサンプリングを設定して、384KHz/32bitで再生できているのか確認しました。

まずは96KHz/32bit再生から。

BCLK（ビットクロック）端子を観測しています。BCLKとは音楽データを1bit送るためのクロック信号です。96KHz/32bit再生では、

96KHz × 32bit × 2ch(L/R) = 6.144Mbit/sec

つまり 6.144MHz のBCLKが必要になります。オシロの観測画像を見ると6.144MHzの信号が出ているので、きちんと96KHz/32bitで動作していることが分かります。

続いて192KHz/32bit。

192KHz × 32bit × 2ch(L/R) = 12.288Mbit/sec

そして384KHz/32bit。

192KHz × 32bit × 2ch(L/R) = 24.576Mbit/sec

ということで、24.576MHzのBCLKが出ています。

Volumio Ver1では、msBerryDACで384再生はソフトに手を入れない限り無理だったので確認していなかったのですが、Volumio2により無事384KHz/32bit再生されていることを確認できました。

768KHz/32bitを設定したら……

Volumio2のアップサンプリングって「768KHz再生」も設定できるのです。興味そそられますよね！

もちろん試して見しまたが、無理でした（笑）。設定自体はできるし、その状態で再生もできるのですが、768KHzに設定してもBCLK=24.576MHzだったので384/32で再生されてるだけでした。

よく考えたら、載ってるクロックが24.576MHzなのでこれ以上のBCLKはどうやっても無理に決まってた（笑）*2

ssh有効化（メモ）

• http://volumio/dev/ にアクセス。

まとめ

• Volumio2は今では成熟して十分使いやすい（Ver1を使う必要はなくなった）
• ジャケット画像を勝手に拾ってくるのはなにげに便利。
• msBerryDACで384KHz/32bit再生をハードウェア的に確認した。

ちなみに、波形が鈍っているのはプローブの設定間違えたせい……。