おうちクラウドをIPv6に（なるべくネイティブに）対応させた話

• おうちクラウド とは：
  ここでは各種（Web）サービスを自宅サーバーによりホスティングしており、尚且つその構成が各種クラウドサービスライクに利用できる状態にあることを指す。

つまり自宅サーバーの一種です（暴論）。

拙宅には最近流行りのマンション共有無料インターネット回線が引かれています。
ベストエフォート1Gbps。恐らくIPv4 over IPv6によるIPoE接続で、上流のルーターからIPv4プライベートアドレスと「インターネット側からUnReachableな」IPv6グローバルアドレスが降ってきます使えねえな。
つまり、そのままでは外出先（インターネット側）から我が家の潤沢な計算資源や記憶装置にアクセス出来ません。
従って、VPNなりトンネルサービスなりで疎通を取る必要があります。
我が家では一般のご家庭によくあるYAMAHAのルーターを使って、VPNサーバー兼リバースプロキシとして構成したさくらのVPSとの間にIPv6でL2TPv3/IPsecトンネルを張り、そのトンネル内にリバースプロキシでさくらのVPSのグローバルIPが受けた着信をIPv4プライベートアドレスに変換して流していました。
（※一時期はSocatでIPv6-IPv4変換していましたが、その後VPS側にリバースプロキシを移しました）
しかし独自ドメインで自分のプロフィールサイト（兼、自分が開発したシステムの動作確認や各種ソリューションの試用サイト）を運営していると、意外とネイティブにIPv4/IPv6デュアルスタック出来ないことに気が付きます。

例えばメールサーバー。
IMAP全盛のこのご時世、メールサーバーの容量など気にせずに独自ドメインのメールアドレスを運用したいですよね？
故に、さくらのVPSを使って自宅にトンネルする構成で、自宅ネットワーク上にメールサーバーを構築したとしましょう。
IPv4であれば、ポートフォワードNATにより送信元IPアドレスが隠蔽されない状態でパケットが届きます。
しかしIPv6の場合どうでしょうか。HTTP/HTTPSであればリバースプロキシがあればよしなに取り計らってくれます。しかしIMAPやSMTPに対し同様のソリューションを見つけることは、私には出来ませんでした。
どの構成例を当たっても「メールサーバーには直にReachableなIPv6アドレスが当たっている」のです。
ではVPSにメールサーバーを置けばいいじゃないか？
ご尤もです。課金して25GBの容量を50GBに、50GBの容量を100GBにすれば良い。それで十分大概のメールサービスが提供する容量を超える大容量メールサーバーが出来ます。
或いは、Google Workspaceなどにメールサービスを委任しても良いでしょう。
しかし、それは「おうちクラウド」上に載っているサービスではない。おうちクラウドを称する以上、どうしても避けられないサービス（インターネットからReachableなグローバルIPの確保）以外は自宅のサーバー上に展開するべきである、という私の信念に反します。

或いは、さくらのVPSを契約すると付属してくるネームサーバーサービス。
さくらのVPSはIPv6をサポートしています。
しかしそれは全てのサービスがIPv6に対応していることを意味しません（少なくともこの記事の執筆時点では）。
世間様ではIPv6シングルスタックの端末・回線も出てくるこのご時世に、さくらのネームサーバーにはIPv4アドレスしか振られていません。
一応各種IPv4-IPv6相互変換サービスもあるとは言えども、ネイティブにIPv6対応していないネームサーバーって正直どうなの？という思いは日に日に募っていきました。

さて、そんな折に下掲のような記事を発見しました。

この記事で私的に重要だったのは、「VPN接続した端末にIPv6アドレスも配布する」という点。
え、VPSにIPv6グローバルアドレスたくさん割り当ててるサービスがあるの！？と目が点になりましただってさくらのVPSは1つしかくれないから……。
多分VPS屋さん的にはVPS上のDockerなどのコンテナに直にIPv6アドレスを割り当てたり、セカンダリアドレスとして割り当てたりするような想定をしてるんだと思うんです。が、幾らIPv6アドレスが膨大だからって、そんな大量にしかも割と自由にアドレス決めれるアドレスブロックくれちゃうんならおじさんみたいな逸般の誤家庭の皆さんは喜んでブリッジ接続して自宅内にそのIPv6アドレスを引き込んじゃうぞヤッター！
ちょっと調べてみた結果、国内にデータセンターがあるサービスで複数のIPv6アドレスをくれて現実的な課金額に収まるサービスは、次のようなものがありました。

• Conoha VPS
• ABLENET VPS
• Vultr Cloud Compute

調べてみるとあるものですね。他にも探せばあるかも知れませんが、取り敢えずは上記3サービスのみに絞って話を進めます。

• Conoha VPS
  IPv6アドレスを17個くれます。でも転送量制限はないけど転送速度は100Mbpsに律速されるし、レイテンシ厨の私にとって東京という遠隔地にデータの出入り口を置くのは考えられないことなので除外。
• ABLENET VPS
  IPv6アドレスを65535個くれます。IPv6アドレスで言うと一番後ろの4桁分。転送量制限はないけど転送速度は200Mbpsに律速。データセンターが大阪にあるとのことなのでレイテンシ厨の私もこれにはニッコリ。でもちょっとお値段高めでコスパがアレなので今回は見送り。
• Vultr Cloud Compute
  上掲記事の構成例でも採用されている最近規模拡大中のクラウドサービス。少し前見た時はリージョンが少なかったが、いつの間にか大阪リージョンが生えていた。なんとIPv6アドレスを/64ブロックでくれる。使い切れんじゃろう常考。
  無料転送量の枠が毎月2TB（アカウントに対して）バンドル＋契約インスタンス毎に転送量の枠が試用時間に比例して付与。枠を超えたら1GBあたり0.01ドルの従量課金。
  正直お金を落とすなら国内企業に落としたかったのが本音だったが、アドレス数と「標準提供されてるネームサーバーがIPv4/IPv6デュアルスタック」なのと「AMD EPYCのインスタンスがある」のと「当該インスタンスが月6.6ドル」と言う魅力には抗えなかったよ……（採用）。

というわけで（何が）、上掲記事の構成例でも採用されていたVultr Cloud ComputeのAMD High Performanceの大阪リージョンのインスタンスを採用。
アカウント作成時に支払い情報を登録するんですが、クレジットカード（楽天VISAとAmazon Prime Master）はどちらも通りませんでした。ぐぬぬ（私が無知なのかも知れませんがこのカード達海外のサービスの決済に使えないんですっけ？？？？）。
しかし賢い私はその場でPaypalのアカウントを作成して10ドルチャージして無事契約できたのでした。

気になるレイテンシは自宅からPing飛ばすとIPv4/IPv6共に25〜110msのあたりをウロウロしている感じでした。Tracerouteするとホップ数がかなり多いので、ネットワーク的にパケットが回り道をしているのかも知れません。レイテンシに限るならさくらの方が速い。
ネットワーク構成についてはほぼ上掲の記事の通り。異なるのは（アドレス等は適宜読み替えてください）、

• IPアドレスは固定するしDNSはVPSインスタンスまたはVultrのリカーシブDNSを明示的に指定するので、dnsmasqは不要（というか、設定が下手なのか上手く動作しなかった）。radvdとndppdは必要。
• tapデバイス内に通すのはVPSでNATしたプライベートIPv4アドレスと、上流ルーターから/64で振られたアドレスブロックから/78で切り出したアドレスブロック。
  ※Vultrは再起動等では変化しないIPアドレス/アドレスブロックがインスタンスに対して固定的に「DHCPで」与えられます。
• radvdのconfを例から以下の様に変更。

/etc/radvd.conf

interface tap
{
        AdvSendAdvert on;
        AdvManagedFlag on;
        prefix 2001:db8::8964:/78
        {
                AdvAutonomous on;
                AdvOnLink on;
                AdvRouterAddr on;
        };
        RDNSS <<Vultrが指定するIPアドレス>>
        {
        };
};

• ndppdのconfを例から以下の様に変更。

/etc/ndppd.conf

proxy enp1s0 {
        router no
        timeout 500
        autowire yes
        keepalive yes
        retries 3
        ttl 30000
        rule 2001:db8::8964:/78 {
                static
        }
        rule 2001:db8::8964:8964:8964:8964/128 {
                static
        }
}

• VPSのtapデバイスにはサービスの起動スクリプトでStaticにIPv4/IPv6（2001:db8::8964:0:0:1）のアドレスとルートを付与
• VPSのSoftEtherに対し拙宅内のIPv6アドレスを持つVMからカスケード接続し、ローカルブリッジは拙宅内のIPv6アドレスが流れていないクローズドな別のネットワークにブリッジ。
• 宅内のVMはDHCPではなく固定でアドレスを指定し、デフォルトゲートウェイにVPSのtapデバイスに付与したIPアドレスを指定
• nmcliでのmetricの調整は（拙宅の場合では）不要だった
• IPv6アドレスに8964をいっぱい含んでいるのはワンチャン某国からのアクセスが弾かれないかな的な期待を込めてます。なんで弾かれるかは知らんけど。

これで無事（？）おうちクラウド側のVMに割り当てたIPv6固定アドレスに対し、外側からも疎通が取れるようになりました最初の動作確認にWindowsを使っていたのでWindowsファイアウォールに阻まれてPingが通らなかったのは秘密。ここに辿り着くまでに3日費やしました。と言うか1日で疎通したのに2日目にあれこれ弄ってる内に繋がらなくなって、3日目で復旧しました。
当たり前ですがVPS側のファイアウォールでフォワードするパケットは絞ってありますし、Vultr標準機能のFirewallの方で上流ルーター側でも絞ってあります。
また余談ですが、Vultrではデフォルトで上流ルーター側で、外部宛の発呼に対するファイアウォールにOP25Bが設定されています。このため、VPSの背後に配置したローカル側のVMに建立したメールサーバーからSMTPを発呼しても、上流ルーターはVPSに配布するIPアドレス/アドレスブロックに対しファイアウォールで叩き落とします。
これを解除申請して申請が通ると、コントロールパネルから再起動を促されます（VPS側から「shutdown -r now」しても適用されません）。
日本時間で夜に申請して1時間後ぐらいに返事が来て、それに返事をしたら翌朝には解除のお知らせが届いていた感じですね。
まあこのメールサーバーの構築もすったもんだしたのですが、話の本筋からは外れるのでまた別の機会にしたいと思います。
あと地味にDDoS対応（有償）もあります。DDoS攻撃が始まってからの事後適用もできるみたいなので（反映にタイムラグはあるみたいですが）、お値段の割にかなり高機能と言っても良いのではないでしょうか。

まとめ

　先行例を少しアレンジする形で、IPv6アドレスを複数払い出してくれるVPSサービスを利用して、VPNにより見かけ上VPSの中のネットワーク上にある端末（おうちクラウドのVM）に対し、インターネットからReachableなIPv6アドレスを割り当てる事例の再現が出来た。

　これにより、おうちクラウドでホスティングしているサービスをネイティブにIPv6対応させることが出来た。

参考文献