こんにちは、去年のAdvent Calendarぶりくらいでのブログ記事となります。
Qiita iOS Advent Calendar 2021 2nd 15日目の記事になります。
iOS15より新機能(現時点ではベータ版)として搭載されたPrivate Relayについて自分なりに調べてみた内容をメモ書きしていきます。
今後の自分の趣味で運用しているWebサーバなどのトラブルシュートする際などでにいつか役に立てば良いかなと思います。
当然Googleで調べると日本語のブログ等でもPrivate Relayについての記事は沢山みつかりますし、先駆者の方達により情報は出切ってしまっているのではと感じていますが、
Private Relayについてがどう言うものかと言う点についてはほぼ省き、実際の動作とCache DNSサーバにて特定FQDNをNXDOMAIN応答させPrivate Relayを強制OFFにさせる動作も試します。
なお、Apple Developerのページでも Private Relayに関する情報が公開されており、こちらの内容を参照しながら実際に動作の確認もしていきたいと思います。
developer.apple.com
内容はiOSバージョンや環境によっても変わると思いますので、参考程度にご覧いただければと思います。
またサンプルのtcpdumpデータはマスクの為に一部情報を書き換えています
iCloud Private Relayとは
iCloud+で有料プランを使ってる方に提供されているベータ機能で、Appleの用意したIngress Proxyと3rd PartyのEgress Proxyから成り立っているProxyを経由してWeb等へセキュアにアクセスできますよな感じのもの。
QUICだったり、ODoHだったり今時な仕組みが使われてます。
詳しい仕組み等はこちらを参照ください。
https://datatracker.ietf.org/meeting/111/materials/slides-111-pearg-private-relay-00
今回の調査環境
- iOS 15が使えるiPhone
- iOSは15.0.2時点のもの。現時点で最新版ではありません。。
- 自前Zone DNSサーバ
- 自前で取得したドメインを利用してPrivate RelayのEgressからの非再起問い合わせを確認してみる用
- 自前Webサーバ
- 80(http),443(https)でWebを立ててPrivate RelayのEgressからの着信を確認してみる用
- 自前Cache DNSサーバ
- Private Relayを抑止する動作確認をしてみる用
- 今回はIPv4でのみの確認
Private RelayをONにしてWebサーバにアクセス
特に設定は変えずにWebアクセスを試す
権威DNSサーバでのtcpdump結果
今回用意した自前WebサーバのFQDN には自身で取得したドメインを利用しており、ドメインを管理してしてる自前Zone DNSサーバにもEgress Proxyからの通信が来ると思ったので、自前Zone DNSサーバのtcpdump結果をまず確認してみます。 tcpdumpを確認したところ、Egress Proxyを運用している(?)事業者のSource IPからのアクセスを確認。
20:30:31.846786 IP X.X.117.196.49676 > [DNSサーバのIP].53: 6911 [1au] AAAA? www.example.com. (50) 20:30:31.847011 IP [DNSサーバのIP].53 > X.X.117.196.49676: 6911*- 0/1/1 (107) 20:30:31.847595 IP X.X.117.196.13557 > [DNSサーバのIP].53: 40391 [1au] A? www.example.com. (50) 20:30:31.847726 IP [DNSサーバのIP].53 > X.X.117.196.13557: 40391*- 1/1/2 A [WebサーバのIP] (99) 20:30:31.850112 IP X.X.117.196.54201 > [DNSサーバのIP].53: 6149 [1au] DNSKEY? www.example.com. (46) 20:30:31.850239 IP [DNSサーバのIP].53 > X.X.117.196.54201: 6149*- 0/1/1 (103)
Webサーバでのtcpdump結果
自前Zone DNSサーバへアクセスのあった同一事業者のSource IPレンジよりアクセスがありました。
なお、このWebアクセスのSource IPについては以下のAppleのサイトで公開されているのですが、そのリストに記載のあるIPでした。
今回のPrivate Relayの設定としては、「IPアドレス位置情報」を「おおよその位置情報を保持」で使用です。
https://mask-api.icloud.com/egress-ip-ranges.csv
ちなみに、自前Zone DNSサーバにアクセスしてきたNWレンジについては上記リストに記載がないため、仮にZone DNSサーバでなにかしら制御している(いないと思いますが)場合は対策のしようはなさそうです。
20:31:10.836038 IP 104.28.101.191.34416 > [WebサーバのIP].443: Flags [.], ack 1401, win 67, length 0 20:31:10.836025 IP 104.28.101.191.34416 > [WebサーバのIP].443: Flags [.], ack 2801, win 70, length 0 20:31:10.836067 IP 104.28.101.191.34416 > [WebサーバのIP].443: Flags [.], ack 4097, win 73, length 0 20:31:10.836184 IP [WebサーバのIP].443 > 104.28.101.191.34416: Flags [P.], seq 4097:4501, ack 518, win 219, length 404 20:31:10.837824 IP 104.28.101.191.34416 > [WebサーバのIP].443: Flags [.], ack 4501, win 76, length 0 20:31:10.860840 IP 104.28.101.191.34416 > [WebサーバのIP].443: Flags [P.], seq 518:644, ack 4501, win 76, length 126 20:31:10.861160 IP [WebサーバのIP].443 > 104.28.101.191.34416: Flags [P.], seq 4501:4552, ack 644, win 219, length 51 20:31:10.862780 IP 104.28.101.191.34416 > [WebサーバのIP].443: Flags [.], ack 4552, win 76, length 0
また、Port443のhttpsアクセスした後に、Port80向けにhttp通信させてみたところ、Port80向けでもEgressを通るらしい。こちらも上記のリストには存在しないレンジでした。
20:34:40.109851 IP 8.37.43.245.20332 > [WebサーバのIP].80: Flags [P.], seq 3476282098:3476282488, ack 3142115709, win 64, length 390: HTTP: GET / HTTP/1.1 20:34:40.109892 IP [WebサーバのIP].80 > 8.37.43.245.20332: Flags [.], ack 390, win 219, length 0 20:34:40.110173 IP [WebサーバのIP].80 > 8.37.43.245.20332: Flags [P.], seq 1:342, ack 390, win 219, length 341: HTTP: HTTP/1.1 200 OK 20:34:40.112625 IP 8.37.43.245.20332 > [WebサーバのIP].80: Flags [.], ack 342, win 66, length 0 20:34:45.115436 IP [WebサーバのIP].80 > 8.37.43.245.20332: Flags [F.], seq 342, ack 390, win 219, length 0 20:34:45.118052 IP 8.37.43.245.20332 > [WebサーバのIP].80: Flags [F.], seq 390, ack 343, win 66, length 0 20:34:45.118061 IP [WebサーバのIP].80 > 8.37.43.245.20332: Flags [.], ack 391, win 219, length 0
Private Relayを自前Cache DNSサーバで抑止する
一通りPrivate Relayが動いたことを確認したので、公式サイトにもあるPrivate Relayを組織内DNSで落とす方法を試したいと思います。
対象FQDN
mask.icloud.com mask-h2.icloud.com
まずはON時のDNS Queryを確認してみる
このテストでは回線をWifiに接続して、Wifi設定からDNSを手動変更し自前Cache DNSサーバに設定しなおしてテストする。
しかしPrivate Relayを既にONにしてしまっていたからかOFF/ONを繰り返してもCache DNSサーバ側でtcpdumpしてもDNS Queryは発生しなかった。
その為、iPhoneを再起動しPrivate RelayをONにした所、以下の様なDNS Queryを確認しました。
何回かやったのですが実際はPrivate RelayのON/OFF動作はあまり関係なく、何かのタイミングでチェックが走っている模様で、初回については端末を起動したタイミングでDNSを引きにいっているようにも見受けられました。
ちなみに、Aレコードだけではなく、Type65(HTTPSリソースレコード)もQueryしてきてました。
(注:以下はicloud.comで抽出してます。)
21:50:09.015535 IP [WifiでのIP].58586 > [Cache DNS IP].53: 64701+ Type65? mask.icloud.com. (33) 21:50:09.017628 IP [WifiでのIP].58719 > [Cache DNS IP].53: 30712+ A? mask.icloud.com. (33) 21:53:21.266950 IP [WifiでのIP].51312 > [Cache DNS IP].53: 25713+ A? setup.icloud.com. (34) 21:53:21.266970 IP [WifiでのIP].50433 > [Cache DNS IP].53: 57346+ Type65? setup.icloud.com. (34) 21:53:21.267995 IP [WifiでのIP].63387 > [Cache DNS IP].53: 27558+ A? p46-acsegateway.icloud.com. (44) 21:53:21.268912 IP [WifiでのIP].64805 > [Cache DNS IP].53: 10065+ Type65? p46-acsegateway.icloud.com. (44) 21:53:27.533742 IP [WifiでのIP].61778 > [Cache DNS IP].53: 55985+ Type65? gateway.icloud.com. (36)
実際に自前Cache DNSサーバで抑止
今回用意した自前Cache DNSサーバはISC BINDを使って構築しましたので、BINDのRPZを用いてNXDOMAINを返す様に設定してみます。
RPZを使わずともzone情報を空で作成すれば簡単で動作も問題無いと思います。
(試す際は allow-query の許可範囲等に気を付けてください)
BINDの設定をする
/etc/named.confのoptions内に以下を追加
response-policy {
zone "mask.icloud.com.";
};
/etc/named.conf内に以下を追加
zone "mask.icloud.com." IN {
type master;
file "mask.icloud.com.zone";
};
/var/named配下にmask.icloud.com.zoneを作成し以下を書き込み (内容は適当です。。)
$TTL 60
@ IN SOA localhost. root.localhost.(
1 ; Serial
28800 ; Refresh
14400 ; Retry
3600000 ; Expire
300 ) ; Minimum
IN NS localhost.
mask.icloud.com IN CNAME .
以上の設定が完了したらnamedサービスをを立ち上げ直します
起動後にdig等で確認しNXDOMAINになることを確認します。
Private Relayの動作確認
再度iPhoneを再起動して動作を確認します。
すると今度はmask.icloud.comでの名前解決に失敗したためか、mask-h2.icloud.comの名前解決が発生して成功し、Private RelayがONにできてしまいました。
最初から両方NXDOMAINにするようにしておきましょう。。
先程設定した要領で「mask-h2.icloud.com」もRPZに設定します。
22:35:04.421780 IP [WifiでのIP].63977 > [Cache DNS IP].53: 45839+ Type65? mask.icloud.com. (33) 22:35:04.421797 IP [WifiでのIP].59973 > [Cache DNS IP].53: 65333+ A? mask.icloud.com. (33) 22:35:04.439444 IP [WifiでのIP].53626 > [Cache DNS IP].53: 10553+ Type65? mask-h2.icloud.com. (36) 22:35:04.441535 IP [WifiでのIP].63125 > [Cache DNS IP].53: 54467+ A? mask-h2.icloud.com. (36)
再設定を終え、再々度iPhoneを再起動して確認します。
すると・・・・
iPhone上にてPrivate Relayが現在接続しているNWでは使えない旨のメッセージが表示されました。
「プライベートリレーなしで使用」を選択をすると、Private Relayが強制的に排除されてOFF時と同じく、接続している回線からのWebにアクセスになる事を確認できました。
今回試した事は以上となります。
最後に
今回は個人的な時間が無く、どのブラウザ経由だとPrivate Relayを経由するのかや、NXDOMAINではなく何かしらIPアドレスを応答する場合の動作等の確認ができなかったので、今後試そうかと思います。
またmasOSでも同様にPrivate Relayが使えるようなので今後試したいとも思います。
一応、iPhone側でのtcpdumpも取っていたのですがログを吹き飛ばしてしまいましたので無かったことにしております。。。
それではよいお年を。
