内部DNSをTermuxのDNSMASQで動かす!

じゃんくはっく
じゃんくはっく

内部ネットワークから参照するDNSを作ったよ!

それって、どんなDNSなの?

ぴー
ぴー
じゃんくはっく
じゃんくはっく

例えば、example.jpだと192.168.1.1にアクセスできるようにするとかできるよ

UターンNAT対策?

ぴー
ぴー

そうなんですよねー。UターンNAT対策で内部DNSが欲しかったんです。

内部DNSを低消費電力サーバのスマホtermuxで動かしたいなと思って、いろいろ格闘していました。先日はOpenWrtというルータ上で動かしていましたが、今回は、root化したスマホ上のtermuxで動かしてみました。53ポートで動かすのでroot化が必要ですが、termuxのrootパッケージの1つ、dnsmasqを使って内部DNSを作ろうと思います。

dnsmasqとは?

公式:Dnsmasq

http://www.thekelleys.org.uk/dnsmasq/doc.html

比較的、軽量でDHCP、BOOTPやPXEにも対応しているDNSサーバでOpenWrtにも使われていたります。自ドメイン以外は指定のDNSに転送して応答してくれます。内部ネットワーク向けの簡易なDNSとしては十分な機能をもっていますね。

今回は、IPv4で自ドメインの応答とそれ以外は8.8.8.8のDNSにフォワードして応答してもらうだけのシンプル設定です。DHCPなどそれ以外の機能はつかいません。

Termuxのdnsmasqは?

ポート53で動かすので、root化したスマホにtermuxを動かしている必要があります。1024番ポート以下はrootじゃないとバインドできません。パッチ内容は以下から参照できます。

termux-root-packages:dnsmasq

URL

やってみましょうか!

ステップ1 インストール

インストール自体は簡単です。root-repoパッケージを入れてから、dnsmasqを入れるだけです。

$ pkg install root-repo -y
$ pkg install dnsmasq -y

本体とmanなどが入ります。サイズは264Kと小さいですね。

$ ll /data/data/com.termux/files/usr/bin/dnsmasq
-rwx------ 1 u0_a143 u0_a143 264K Aug 17 02:40 /data/data/com.termux/files/usr/bin/dnsmasq*

ステップ2 設定

Termuxのdnsmasqだと、設定ファイルはデフォルトで無いので作ります。

$ cd $PREFIX/etc
$ vi dnsmasq.conf 

内容は以下です。ほどよく読み替えてください。

ホスト設定:$PREFIX/etc/hosts-dnsmasq
ログ:$PREFIX/var/log/dnsmasq.log
このホストIP:192.168.1.38
Termuxユーザ:u0_a143
ドメイン:gpl.jp
フォワードするDNS:8.8.8.8

listen-address=127.0.0.1,192.168.1.38
port=53
bind-interfaces
user=u0_a143
group=u0_a143
no-poll
# プライベートIPアドレスの逆引きを上位DNSサーバに転送しない
bogus-priv
# ドメインの無いホスト名のみ問い合わせの場合、上位DNSサーバに転送しない
domain-needed
# ローカルエリア内のドメインを指定
local=/gpl.jp/
# ホスト名で問合せされた時、下記のdomain=で指定されたドメイン名を補完
expand-hosts
# 補完するドメイン名
domain=gpl.jp

# LocalDNS
addn-hosts=/data/data/com.termux/files/usr/etc/hosts-dnsmasq
server=/gpl.jp/192.168.1.38
server=/1.168.192.in-addr.arpa/192.168.1.38
log-queries
log-facility=/data/data/com.termux/files/usr/var/log/dnsmasq.log

server=/localnet/192.168.1.38 # change ip for your ip-server
server=8.8.8.8
no-resolv 

ホスト設定:$PREFIX/etc/hosts-dnsmasq は以下となります。

192.168.1.38    f2
192.168.1.47    p3
192.168.1.47    hack
192.168.1.47    junkhack

resolvファイルは自サーバを参照するよう以下にしておきます。

$ cat resolv.conf 
#nameserver 8.8.8.8
nameserver 192.168.1.38

ステップ3 起動

53ポートでバインドさせるので、rootで起動します。

$sudo dnsmasq -C $PREFIX/etc/dnsmasq.conf

ステップ4 確認

確認です。明示的に dig @hostip domain と@でdnsを指定するとより良いです。

$ dig f2 +short
192.168.1.38

$ dig -x 192.168.1.38 +short
f2.gpl.jp.

$ dig hack.gpl.jp +short
192.168.1.47

$ dig yahoo.co.jp +short
182.22.59.229
183.79.135.206

ホスト名のみでも大丈夫ですね。FQDN自ドメインも引けますし、逆引きもできます。管理外はフォワードして応答してきました。

例えばまったく違うドメインを指定

$ cat hosts-dnsmasq
192.168.1.38    f2
192.168.1.47    p3
192.168.1.47    hack
192.168.1.47    junkhack
192.168.1.111   test.example.jp

このように、違うドメイン名をFQDNで記載したら参照できるのでしょうか?

設定変更・再起動

$ sudo killall dnsmasq
$ sudo dnsmasq -C $PREFIX/etc/dnsmasq.conf

参照できるか引いてみます。

$ dig test.example.jp +short
192.168.1.111

$ dig -x 192.168.1.111 +short
test.example.jp.

参照できますね。これって設定ファイルのserver行でドメイン指定しなくてもいいんですかね? 設定項目はもっとシンプルにできるのかもしれませんが、追求するのはヤメにしておきます。

まとめ

同じ設定を、UmidigiF2では動きましたが、Pixel3ではフォワーダーが動かなかったです。

・UmidigiF2では動作し、Pixel3ではフォワーダーが動かない原因は不明
・機会があれば、BOOTPやPXEも試してみたい
・FQDNで記載すれば違うドメイン名でもOK
・MXやテキストレコードなどはどうやって指定するのだろう?

あとがき

今の所不具合はなさそうです。もう1週間ほど動かして問題なさそうであれば今のWordPressサーバを統合しようかなと思います。メインPCからもこのDNSを参照していますが速度的にも特に問題はない感じです。

著者にメッセージ

間違いのご指摘など、コメントじゃなくて、個人的にやりとりしたい場合はこちらからどうぞ。お返事が遅くなるときもありますが、ご了承を。

2020/10 site24x7 でのSLA状況など統計データ

じゃんくはっく
じゃんくはっく

引っ越ししてからのSLAデータ報告です!

site24x7のレポート?

ぴー
ぴー
じゃんくはっく
じゃんくはっく

そうそう。有料会員になったんでとりあえず使っています!

99.95% って難しそうだね!

ぴー
ぴー

site24x7のスターターパックというのを10月から始めてみました。いわゆる監視サービスなんですが10ドルで契約できるので、ちょっと使い始めています。

稼働率・SLA99.95%をスマホ自宅サーバで目指せ!まずは1ヶ月間

LINK

とりあえず、SLAレポートが出せるのでこれを月末に出していこうかなと思います。

2020・10のSLA

まずは結果から。ダウンタイムの合計3 時間 5 分あって、SLAは99.567%となり目標の99.95%には届きませんでした。99.95%とは1ヶ月に21.6分以内のダウンタイムに留めないといけません。しかし、3時間も止めてしましました。

原因は?

5日の停止はDNSの設定ミスです。27日と28日は内部ネットワークを少し変更してその影響で少し止まってしまいました。30日は、NGINXがBadGatewayを出して本格的に停止していました。今の所、root化したtermuxでNGINXを動かすとこの現象が発生しています。これはなんとかしないとだめですね。設定関連での停止は、今後以下のように対策しようと思います。

・設定変更後、5分は監視レポートが飛んでくるか確認する。

なかなか設定ミスの間違いには気がつきにくいです。とりあえず何か変更したら、5分は監視サービスの動きを見ることで対応しようと思います。

まとめ

今回の教訓は以下となります。

・引っ越し当初なんで設定することがたくさんあった
・設定変更後は、監視サービスの動きを5分は見て見ることにする
・サーバ1つだとやっぱりきびしい。多重化が必要。
・root化したNginxだとBadGatewayが出てしまう。なんとか対策しなくとだが根本原因がまだ不明

あとがき

UmidigiF2をroot化したので、とりあえずこっちに戻して様子を見ようと思いますが、めんどくさいのでちょっと作業は中断。スマホサーバを安定して動かすのは難しいです。

著者にメッセージ

間違いのご指摘など、コメントじゃなくて、個人的にやりとりしたい場合はこちらからどうぞ。お返事が遅くなるときもありますが、ご了承を。