プライバシーを守るポータブルルーター：UnboundでOpenWrt (LEDE)にDNS-Over-TLSサポートを追加する

本日は、GL-AR750でDNS-Over-TLSを設定する方法について、Junade Ali氏が執筆した詳しいガイドをご紹介します。DNS-Over-TLSが何かわからない方のために、少し豆知識をお届けします：

あなたを監視するISPは、インターネット上でのあらゆる行動からデータを抜き取り、広告主やマーケティング会社に販売できます。DNS-Over-TLSは、ユーザーのプライバシーを守るための新しいWebブラウジング用セキュリティツールです。DNSリクエストを暗号化し、中間者攻撃によるDNSデータの盗聴や改ざんを防ぎます。

---

手順だけを先に読みたい場合は、次のセクションまでスクロールしてください。ただ、TLSハンドシェイクのように私はかなり冗長なので、この導入部分もお楽しみください。

次の場面を想像してください。私はレストランにいて、個人的な電話をする必要がありますが、運悪く自分のスマートフォンのバッテリーが切れています。この問題を回避するため、友人のスマートフォンを借りて番号をダイヤルし、プライバシーを守るために外へ出ます。通話が終わったら店内に戻り、スマートフォンを返します。

スマートフォン自体には私の会話内容は保存されませんが、最近発信した番号の履歴は残ります。私がスマートフォンを借りた友人が見ようと思えば、会話の内容を具体的に知らなくても、私が実際に誰に電話したのかは簡単にわかってしまいます。

誰と話したかというデータだけで、会話について非常に多くのことがわかる場合があります。誰かが感情的サポートホットラインや債権回収業者に電話した場合、発信先番号から会話の内容について多くを推測できるでしょう。

インターネットを閲覧するとき、私たちは会話を保護するために暗号化を使います。HTTPS経由でWebサイトに接続すると、ブラウザーに緑色の南京錠が表示され、あなたとWebサイトのサーバーの間にいる攻撃者が会話内容を見ることは計算上困難な形で暗号化されていることを知らせます。

以前、特定の状況下ではこの暗号化を取り除くことが可能であること、そしてWebサイトがそれを防ぐために使用できる緩和策についてブログに書きました。残念ながら、オンラインプライバシーにはさらに根本的な問題があります。

一般的なIT知識として、ブラウザーがWebサイト（例：cloudflare.com）へHTTP接続を行う前に、クライアントはHTTP接続先のIPアドレスを調べるためDNSクエリを行う必要があります。IPアドレスの代わりにホスト名を使って接続する場合、これは他のアプリケーション層プロトコルでも同じです。DNSの入門として、当社のLearning CentreにはDNSの基礎に関する記事があります。

HTTP自体の暗号化技術はかなり長い間存在してきましたが、DNS向けにそのような暗号化手法が標準化されたのは最近のことです。DNSトラフィックが暗号化されているかどうかわからないなら、おそらく暗号化されていません。

実際には、HTTPSを使用するWebサイトに接続すると、会話内容は暗号化されていても、接続を傍受できる人物はあなたがどのWebサイトを探しているかを確認でき、（サイトの保護方法によっては）応答を改ざんして別のサーバーと通信させることさえできます。

これは盗聴者にとって特に都合がよいものです。たとえば、あなたのデータをターゲティング広告主に売ろうと無料Wi-Fiホットスポットを運営しているネットワークであれ、ネットワークトラフィックを傍受しながらラテを飲んでいるハッカー（皮肉にも黒いパーカーと目出し帽姿）であれ同じです。

DNSリゾルバーをCloudflareのDNSリゾルバーに切り替えると、より高速なブラウジング体験が得られ、DNSリゾルバーを運用する人々が広告ターゲティングのためにそのデータを売却していないことも確保できます。ただし、Cloudflare ResolverはDNS-over-HTTPSとDNS-over-TLSの両方をサポートしていますが、Cloudflare Resolverとあなたの間の接続が暗号化されるようにするには、DNS over HTTPSクライアントの有効化など、追加の設定手順が必要になる場合があります。

このブログ記事では、OpenWrtルーターを設定してCloudflare Resolverへのアウトバウンドトラフィックを暗号化する方法を説明します。これは、暗号化DNSプロトコルをサポートしていない可能性がある家庭内デバイス（テレビやIoT対応トースターなど）のトラフィックを保護したい場合に特に有用です。ローカルクライアントはルーター上のローカルDNSリゾルバーを明示的に上書きすることもできますが、多くはデフォルトでそれを使用します。

OpenWrt (LEDE)

この記事を書く前の週末に、新しいワイヤレスルーターGL.iNet GL-AR750を注文しました。このルーターは非常に小さなフォームファクターで、「トラベルルーター」として販売されており、従来のWi-FiルーターとしてだけでなくWi-Fiリピーターとしても動作できます。ルーター本体の最も長い辺は、私の人差し指ほどの長さです：

この特定のルーターを注文したのは、そのフォームファクターだけが理由ではありません。ルーター向けに適した組み込みLinuxベースのオペレーティングシステムであるOpenWrtがプリインストールされていることも理由です。2016年5月、OpenWrtはLEDE（Linux Embedded Development Environment）としてフォークされ、2018年1月にOpenWrtプロジェクトへ再統合されました。

LEDEがプリインストールされたルーターをお持ちでない方も、OpenWrtファームウェアを書き込める他のルーターであれば、このブログ記事に沿って進めることができます。詳細はOpenWrt Support Devicesページで確認できます。ただし、デバイスによってはリスクを伴う場合があることにご注意ください。

DNS-over-TLSへの対応（または、その不足）

私が試しているルーターには、内部リゾルバーにキャッシュされていないクエリで使用する上流DNS Resolverを設定するための構成オプションがあります。このローカルリゾルバーは、その後ルーターに接続するクライアントへ推奨されます。

実験のため、Web UIから、このルーターが1.1.1.1、1.0.0.1、2606:4700:4700::1111、2606:4700:4700::1001を上流DNSサーバーとして使用するように設定できます（ネットワークがIPv6アドレスをサポートしていない場合は更新します）：

ルーターのWANポートをコンピューターに接続することで、実際のWANへ出ていく前に、Wiresharkを使ってルーターから出るトラフィックをスニッフィングできます。DNSクエリがルーターのキャッシュにない場合、それは1.1.1.1へ転送されます。私のルーターはDNS-over-TLSを使わず、これらのクエリを暗号化せずに送信しているため、これらのDNSクエリが暗号化されていない形式でインターネット上に送信されているのを確認できます：

Cloudflare ResolverはDNS-over-TLSをサポートしていますが、残念ながら私のルーターは対応しておらず、すべてのクエリを暗号化せずに送信するだけです。

DNS-Over-TLSのセットアップ

デフォルトでは、LEDEには内部リゾルバーとしてDnsmasqがプリインストールされているため、DNS-over-TLSをサポートしていません。リクエストを暗号化できるようにするため、DnsmasqをUnboundとodhcpdに置き換えます。ここで行う手順は、非常に役立つOpenWrt Unboundパッケージドキュメントを基にしています。

始める前に、ルーターへSSHで入る必要があります。パスワードを求められた場合は、Webポータル用に設定したものと同じである可能性が高いです：

LEDEはパッケージマネージャーとして​opkg​を使用します。まずパッケージリストを更新し、次にUnbound-Controlを含むUnboundと、フルバージョンのodhcpdをインストールします：

opkg update
opkg install unbound odhcpd unbound-control
opkg remove dnsmasq

必要であれば、標準ユーザーインターフェースで制御できるように、Unbound用のLuciアプリを追加でインストールすることもできます。

opkg install luci-app-unbound

私のルーターは現在バニラLEDEで動作していないため、これをインストールしてもユーザーインターフェースは変更されません。また、このモジュールは私自身ではテストしていません。

Unboundを導入したら、TLS暗号化を使用するDNSリゾルバーとして1.1.1.1、1.0.0.1、2606:4700:4700::1111、2606:4700:4700::1001をUnboundが使用するように設定を追加できます。私はVimを使い、/etc/unbound/unbound_ext.confにいくつかの設定を追記しました：

forward-zone:
  name: "."
  forward-addr: 1.1.1.1@853
  forward-addr: 1.0.0.1@853
  forward-addr: 2606:4700:4700::1111@853
  forward-addr: 2606:4700:4700::1001@853
  forward-ssl-upstream: yes

Unbound設定ファイル/etc/config/unboundでは、パッケージドキュメントで説明されている必須の設定パラメーターをいくつか追加しました。私の場合、設定ファイルをバックアップし、単純に次の内容を使用しました：

config unbound
  option add_local_fqdn '1'
  option add_wan_fqdn '1'
  option dhcp_link 'odhcpd'
  option dhcp4_slaac6 '1'
  option domain 'lan'
  option domain_type 'static'
  option listen_port '53'
  option rebind_protection '1'
  option unbound_control '1'

ファイルに追加のパラメーターがある場合は、設定したパラメーターを上書きするものがないことを確認してください。特にunbound_controlパラメーターには注意してください。

また、次の設定を/etc/config/dhcpにマージしました（一部の既存エントリはそのまま残しています）：

config dhcp 'lan'
        option dhcpv4 'server'
        option dhcpv6 'server'
        option interface 'lan'
        option leasetime '12h'
        option ra 'server'
        option ra_management '1'

config odhcpd 'odhcpd'
        option maindhcp '1'
        option leasefile '/var/lib/odhcpd/dhcp.leases'
        option leasetrigger '/usr/lib/unbound/odhcpd.sh'

最後に、Unboundの自動起動を有効にして起動します：

service unbound enable
service unbound start

結果は明白です。ルーターとより広いインターネットの間のDNSクエリを傍受すると、それらがTLS v1.2で暗号化されていることがわかります：

まとめ

この記事では、DNSトラフィックを暗号化することがインターネット閲覧のプライバシー保護にどのように役立つかを説明しました。DnsmasqをUnboundに置き換えることで、OpenWrtがDNS-over-TLSを活用し、Webトラフィックの暗号化を支援できるようになります。

---

Junade Ali氏に、この記事を当社Webサイトで共有する許可をいただいたことに感謝します。この記事は2018年4月9日にCloudflareのWebサイトで最初に公開されました： https://blog.cloudflare.com/dns-over-tls-for-openwrt/