目的のEdge DNS実装とIP Anycastアドレス取得までの道のり - route64.org

8 min

language: ja bn en es hi pt ru zh-cn zh-tw

こんにちは、無能です。

Edge DNS及びCDNを作成するためにあがいてます。

現状

擬似的な分散です。

edge.soulminingrig.com のCNAMEに pool.soulminingrig.com を登録しているのはいずれかの分散させるために・・・現状無意味です。

$dig www.soulminingrig.com AAAA +short
edge.soulminingrig.com.
pool.soulminingrig.com.
2400:8500:2002:3317:163:44:113:145
2a11:6c7:f07:156::2

$dig www.soulminingrig.com A +short
edge.soulminingrig.com.
pool.soulminingrig.com.
163.44.113.145
91.98.169.80

なぜか最寄りのサーバからこれでも配信される

あくまでこれでも HTTP の場合クライアント側のおかげでかつすごいのが HTTP クライアントって実質最寄りのサーバーに到達するようになっているんですね。これがDNSサーバがうまいこと振り分けているのかはわかりません。ConoHa DNSを使っているおかげなのかわからないのは詳細仕様まではわかる情報がないため。

ドイツのサーバーから

IPv6:

# curl -I6s https://www.soulminingrig.com/ -vvv 2>&1 | head 
01:36:56.631373 [0-x] == Info: [READ] client_reset, clear readers
01:36:57.350639 [0-0] == Info: Host www.soulminingrig.com:443 was resolved.
01:36:57.350725 [0-0] == Info: IPv6: 2a11:6c7:f07:156::2, 2400:8500:2002:3317:163:44:113:145
01:36:57.350801 [0-0] == Info: IPv4: (none)
01:36:57.350916 [0-0] == Info: [HTTPS-CONNECT] adding wanted h2
01:36:57.350949 [0-0] == Info: [HTTPS-CONNECT] added
01:36:57.350980 [0-0] == Info: [HTTPS-CONNECT] connect, init
01:36:57.351107 [0-0] == Info:   Trying [2a11:6c7:f07:156::2]:443...
01:36:57.351308 [0-0] == Info: [HTTPS-CONNECT] connect -> 0, done=0
01:36:57.351344 [0-0] == Info: [HTTPS-CONNECT] Curl_conn_connect(block=0) -> 0, done=0

IPv4:

# curl -I4s https://www.soulminingrig.com/ -vvv 2>&1 | head 
01:38:31.901521 [0-x] == Info: [READ] client_reset, clear readers
01:38:32.847878 [0-0] == Info: Host www.soulminingrig.com:443 was resolved.
01:38:32.847999 [0-0] == Info: IPv6: (none)
01:38:32.848050 [0-0] == Info: IPv4: 91.98.169.80, 163.44.113.145
01:38:32.848139 [0-0] == Info: [HTTPS-CONNECT] adding wanted h2
01:38:32.848251 [0-0] == Info: [HTTPS-CONNECT] added
01:38:32.848315 [0-0] == Info: [HTTPS-CONNECT] connect, init
01:38:32.848440 [0-0] == Info:   Trying 91.98.169.80:443...
01:38:32.848657 [0-0] == Info: [HTTPS-CONNECT] connect -> 0, done=0
01:38:32.848723 [0-0] == Info: [HTTPS-CONNECT] Curl_conn_connect(block=0) -> 0, done=0

家の環境から

IPv6:

$curl -I6s https://www.soulminingrig.com/ -vvv 2>&1 | head 
01:39:23.182757 [0-x] * [READ] client_reset, clear readers
01:39:23.227731 [0-0] * Host www.soulminingrig.com:443 was resolved.
01:39:23.227855 [0-0] * IPv6: 2400:8500:2002:3317:163:44:113:145, 2a11:6c7:f07:156::2
01:39:23.227996 [0-0] * IPv4: (none)
01:39:23.228072 [0-0] * [HTTPS-CONNECT] adding wanted h2
01:39:23.228171 [0-0] * [HTTPS-CONNECT] added
01:39:23.228253 [0-0] * [HTTPS-CONNECT] connect, init
01:39:23.228369 [0-0] *   Trying [2400:8500:2002:3317:163:44:113:145]:443...
01:39:23.228605 [0-0] * [HTTPS-CONNECT] connect -> 0, done=0
01:39:23.228711 [0-0] * [HTTPS-CONNECT] Curl_conn_connect(block=0) -> 0, done=0

IPv4:

$curl -I4s https://www.soulminingrig.com/ -vvv 2>&1 | head 
01:40:52.285758 [0-x] * [READ] client_reset, clear readers
01:40:52.316059 [0-0] * Host www.soulminingrig.com:443 was resolved.
01:40:52.316177 [0-0] * IPv6: (none)
01:40:52.316239 [0-0] * IPv4: 163.44.113.145, 91.98.169.80
01:40:52.316340 [0-0] * [HTTPS-CONNECT] adding wanted h2
01:40:52.316440 [0-0] * [HTTPS-CONNECT] added
01:40:52.316522 [0-0] * [HTTPS-CONNECT] connect, init
01:40:52.316638 [0-0] *   Trying 163.44.113.145:443...
01:40:52.316822 [0-0] * [HTTPS-CONNECT] connect -> 0, done=0
01:40:52.316929 [0-0] * [HTTPS-CONNECT] Curl_conn_connect(block=0) -> 0, done=0

何度やっても同じ最寄りIPに到達します。すごい。

多分 ConoHa DNS自体がそういう仕組みじゃないと成り立たないから最寄りのIPアドレスから配信されるような感じにしている気もします。

$dig a.conoha-dns.com +short
157.7.32.89
$dig b.conoha-dns.org +short
157.7.33.89

ConoHaのプライマリとセカンダリのDNSサーバーが設定されていて a.conoha-dns.com が死んだ場合に b.conoha-dns.org に問い合わせされなければ意味がありません。こんなことに気づかなかったのかというところですが、どちらかと言えばクライアント側が片方のDNSサーバーが死んだとしたら生きている方に解決しにいけなければプライマリとセカンダリの意味がありません。

よく出来てるなあ・・・。これが A レコード複数登録されていても、ある意味機能しているということですね。

それでももっと分散させたい

実際もはやこれだけでも十分なのですがもっと分散できれば自前分散DNSなり自前分散CDNなりが出来る訳です。現状二拠点のキャッシュサーバが死んだら疎通ができなくなります。

多分大手クラウド業者は圧倒的なインフラ環境と資金を投じてこの分散システムを構築したと考えるとちょっとエゲツない。

お手軽分散を思考

単一障害点になり得なければ良いのならば、ですがIP Anycastで複数の拠点から配信しても同じIPアドレスを発信することができます。但しその条件としてBGPが構築されていることが前提で以下が個人に高いハードルがあります。

  • ASNの取得

  • BGP構築に必要なサブネット値の取得

どちらも費用も手続きも個人じゃとても簡単に出来る気がしません。

つまりはすっ飛ばして IP Anycast さえ、そのIPアドレスさえ取得できれば問題ありません。

ただ基本的に第三者が所有しているIPアドレスを使うことはマナー的にはNGだと思います。

route64.org

https://route64.org/en

見つけました。

IPv6普及のために行っている非営利団体のようです。

但し無料で使えるのは見切れていないですが実質 IPv6 Tunnelくらいで他は基本的に寄付によって利用出来るポイントがもらえるシステムみたいです。そのポイントを使ってBGPやフルマネージドなIP Anycastのサービスが使えるみたい。

金がかかると言っても数ドルくらいでAnycastアドレスが取得出来たりしてすごい。ちなみに帯域制限はあるみたいなのでその点も注意。

あくまでトンネルなので所有することは出来ませんが。

日本語圏内でも取り上げてるとこが無くて困りました。

ちょうどHetznerのIPv4サーバーにIPv6を付与したかったので試してみました。ちなみにHetznerでIPv4が付与されているサーバにIPv6アドレスを追加すると追加月額1$です。IPv6アドレスで金取るんかい・・・と思って付与しなくてよかったです。

実際 IPv6 Tunnel なのでそこだけは注意が必要です。

何気に便利なのは応答遅延酷すぎるVPS等の中継としてこのroute64でSSHクライアントとSSHサーバ側の間くらいとかにあるとこのIPv6アドレスを発行して中継すると結構快適になります。

IPv6 Tunnelを使ってみる

以下で add tunnelbrokerを選択します

image.png

そしてトンネル方法を選択します

image.png

私はお手軽なのとすでにサーバーに入れていたので WireGurad を選択しました。

image.png

これでIPv6を付与したいサーバーのIPv4アドレスを追加します。

つまりはWireGuardクライアント側の設定という訳です。

私の場合は 91.98.169.80 です。

これで WireGurad の設定ファイルが吐き出されるので後は wg-quick up conf-file するだけです。

そう、お気づきの方もいらっしゃるかもしれませんが、このブログの AAAA レコードの二個目のIPv6アドレスはこれで取得したアドレスです。

AnycastサービスはIPv4でも可能

てっきりサービス名からIPv6だけだと思ったら、AnycastアドレスはIPv4も対応しているみたい。すごい。

というわけで、近いうちにAnycastアドレスの取得をしてみようと思います。

それと、IPv4のサブネットの取得は諦めてはいないので出来る限り安いコストで維持出来るような方法がないかしばらくリサーチする時間が必要そうです。

Related Posts