CTO統括室の黒崎です。AWSのBYOIP(Bring Your Own IP Address)がJPNICの割当IPアドレスに対応したので、実際にIPアドレスを持ち込んで使ってみました！
今回は社内ゼミ制度のインターネットゼミの活動の一環として検証しました。
ゼミの環境は商用環境と完全に分離されているため、わざとヘンな設定を入れてみたらどうなるのかも実験しました。
インターネットゼミについては以下をご参照ください。
インターネットゼミ開講のお知らせ
ダークファイバーでOPEN.ad.jpと接続してみた #インターネットゼミ
AWSのBYOIPとは
BYOIP(Bring Your Own IP Address)とは、自社で割り当てを受けているIPアドレスを持ち込めるサービスです。
AWSを利用ユーザは普通はAWSが割り当てを受けているIPアドレスを利用することになりますが、BYOIPを利用するとAWSの上で自社で割り当てを受けているIPアドレスを利用できるようになります。今回はこれをやってみました。
なぜこのタイミングでBYOIPを検証したかというと、今週以下のようなアップデートがあったためです。
Amazon VPC IPAM now supports BYOIP for IPs registered with any Internet Registry
This new feature extends BYOIP support to previously unsupported Internet Registries, including JPNIC, LACNIC, and AFRINIC.
と書かれているようにBYOIPの機能自体は以前からあり、AWSの東京リージョン自体は対応していましたが、IPアドレスの検証フローの都合でJPNIC等でIPアドレスの割当を受けている組織に対応していませんでした。
日本国内ではJPNIC(Japan Network Information Center)からIPアドレスの割当を受けることが多く、インターネットゼミもJPNICから割り当てを受けているため、今まではAWSでBYOIPを使うことができませんでした。今回のアップデートにより新しいIPアドレスの検証方法が追加され、結果的にJPNICを含む全世界のInternet Registrieyが対応となりました。
タイトルで最速(?)と書いた理由ですが、本当に最速かどうかはAWSしか知り得ません。
ただ、BYOIPしたアドレスでインターネットに接続できるようにすると持ち込んだIPアドレスがAWSのAS(Autonomous System)より広報されるため、どの組織がAWSでBYOIPを利用しているのか外部から観測できます。
今回は以下のサイトでAWSが広報しているprefix 1万件強を目視で日本国旗のアイコンが含まれているものを探し、その中でJPNICから割り当てを受けているものを探しました。2024年7月25日時点ではAPNICを使っている組織はあったものの、JPNICはAmazonを除き我々以外には見当たりませんでした。
https://bgp.he.net/AS16509
https://bgp.he.net/AS14618
また、AWSにはBYOASN(Bring Your AS Number)というASを持ち込めるサービスもありますが、こちらはJPNICに対応していないため、BYOASNを使っているケースは考慮していません。
Tutorial: Bring your ASN to IPAM
以上の理由から(※サイバーエージェント インターネットゼミ調べで)最速でやってみたということにします。
BYOIPの設定
手順は以下の公式ドキュメントを参考にしました。
Verify your domain with a DNS TXT record
今回の検証はすでにJPNICからAS番号とIPアドレスの割り当てを受けていることを前提とします。
また、現時点ではIPv4はJPNICに必要な設定を申請中で広報できておらず、IPv6のみ検証が完了したのでIPv6の事例を紹介します。
ROAの作成
ROA(Route Origin Authorization)はIPアドレスが割り当てられていることを証明したり、BGPで広報する経路が正当であることを証明したりするのに使われます。我々が割り当てを受けているIPアドレスをAWSが勝手に広報するわけにはいかないので、ROAを作成することでAWSがそのIPアドレスを広報する正当性を証明できるようにします。
JPNIC側で設定する必要があるのでJPNICのドキュメントを参考に作業しました。
ROAの作成と管理の方法
以下のサイトでAmazonのASであるAS14618とAS16509のROAが作成されたのを確認しました。
https://rpki-validator.ripe.net/ui/
IPAMの作成
AWSコンソールからIPAMを作成します。
Operating Regionsの設定で複数リージョン設定するとprefixごとに使うリージョンを変えられるようです。
IPAMのプールは階層構造にできるため、今回は図のような設計にしました。
逆引きDNSゾーンの設定
ROAの作成によりAWSが我々のIPアドレスを広報できるようになりましたが、AWSは我々のAWSアカウントとそのIPアドレスの関連性を知らないため、正当な管理者であることを証明する必要があります。そのために「Verification Token」というトークンを発行しそれを逆引き用のDNSゾーンに設定する必要があります。
AWSで 2407:a6c0::/32 の中からサブネットを切り出し広報できるようにする場合で、Verification Tokenのnameが「abcd1234」、valueが「token-value」の場合は「abcd1234.0.c.6.a.7.0.4.2.ip6.arpa」のTXTレコードにvalueを設定します。
IPAM PoolでCIDRを登録する
最初に親となるIPAM Poolを作成し、その下にCIDRを登録します。今回は /32 で登録しました。前のステップでVerification Tokenの検証が成功していればCIDRのプロビジョニングに成功するはずです。
親IPAM PoolのCIDRを直接使うことはないので、リージョンに紐づけず、サービス(EC2等)で使う設定も無効にしておきます。
子のIPAM Poolは親のIPAM PoolのCIDRから /48 を切り出して作成しました。このCIDRからVPCに割り当てるCIDRを切り出したいので、リージョンを設定し、サービス(EC2等)で使う設定も有効にしておきます。インターネットに広報できるPrefixは /48 が最長となっているので、CIDRのサイズは /48 以下にしなければいけません。
IPAM Poolに親子関係をつくらずに必要な粒度で独立したprefixを複数作ることも可能ですが、IPアドレスの検証を細かいprefixごとに行わないといけないのが不便そうだったのでこのような形にしました。
経路を広報する
CIDRを作っただけでは経路がインターネットに広報されず疎通できません。経路を広報する設定を入れるとAWSのASから経路が広報されます。Advertiseボタンを押すだけで経路が広報されるのは楽ですね。
実際に広報された経路をゼミのBGPルータで受信できているか確認しました。AWSのAS(AS16509)から広報された経路を4箇所から受信できているのがわかります。
VPCの作成
VPCを作成し、CIDRを割り当てます。IPv6は以前のステップで作った子のIPAM Poolから /56 を切り出して割り当てました。そしてVPCのサブネットにはそこからさらに /64 を切り出して割り当てました。
検証過程でネットワークの設定不備を検出するためにReachability Analyzerを使おうとしたのですが、IPv6に対応していないことをここで初めて知り、設定を見直しミスを見つけました。(ルーティングテーブルにデフォルトルートを入れ忘れていた)
IPv6も対応されるとデバッグ作業が楽になるのでIPv6対応を期待しています。
問題発生
IPAM Poolでは、VPCに割り当てたCIDRが自動でAllocationsに登録され、重複しないように自動で管理されます。
検証過程でVPCを作り直したくなったので、VPCにIPAMから切り出したCIDRを付与したままVPCを削除したのですが、Allocationsが自動削除されず手動でも消せなくなってしまい、再利用不能なprefixが生まれてしまいました。
Allocationsが削除できないとIPAM Poolの削除もできず困ってしまったのでサポートに問い合わせ中です。そのうち修正されると期待していますが、同様の検証をされる場合はCIDRを残したままVPCを削除しないようにお気をつけください。
VPCのIPv6のCIDRは削除してもすぐには消えず一定時間はDisassociatedというステートでCIDRが残るため、terraformなどを使う場合は注意が必要です。
EC2インスタンスの作成
pingだけ通ればいいので、最小構成のEC2インスタンスを作成しました。
サブネットにBYOIPのCIDRが割り当たっているので、EC2を起動するときはBYOIPを特別意識する必要はありません。
EC2インスタンスのIPv6アドレスは 2407:a6c0:318:ca:318:ca:318:ca にしてみました。
サイバーエージェントなので318とcaが交互に現れるように設定しました。おしゃれですね。
tracerouteしてみる
本当にゼミのIPアドレスがAWSで使えるのか試すために手元の環境からEC2にtracerouteを実行してみました。
AWSにゼミのIPアドレスを持ち込めたのが確認できました！！
ちなみにAS0と表示されている部分は実際にはAWSに割当されている 2620:107:4000::/44 の一部で、インターネットには広報されずAWS内部で利用されているように見えます。
AWSから広報されているprefixと同じprefixをゼミのASから同時に広報するとどうなるのか
普通は気軽にそんなことを試そうとすると怒られるんじゃないかと思いますが、ゼミのASは商用環境と完全に分離されているため、壊しても誰にも怒られないのと、壊れているところを見てみたいので試してみました。
外部からどう見えているか確認したかったため、さくらインターネットのLooking Glassを使って確認しました。
AS9370 Looking Glass – SAKURA Internet
AWS(AS16509)から 2001:df3:aac0:318::/48 を広報している状態でゼミ(AS63790)からも同じprefixを広報した結果です。
ゼミ(AS63790)からの経路がなく、依然としてAWS(AS16509)からの経路が表示されています。変化が見られなかったのでAWS側の経路広報を止めてみたところ、ゼミ(AS63790)からの経路が表示されました。
両者を見比べてきるとAS PATHの長さが違うことがわかりました。AS PATHは宛先のネットワークに到達するまでに経由するASのリストで、このリストの長さが短い方が経路が優先されます。ゼミのASは商用環境ではないためIXにも繋がっておらずピアリングもほぼしていないためAS PATHが長くなりがちで、AWSのASからの経路の方がbest pathになりやすいことがわかりました。
これと同時に自宅からpingを打ち続けていたのですが、AWSから経路を広報するのをやめるとpingが返ってこなくなる様子が確認できました。商用環境だったら障害ですね。
さいごに
AWSのBYOIPでインターネットゼミのIPアドレスをAWSに持ち込んでみました。
バリデーションさえ通せばIPアドレスをプールという概念で簡単に管理できることがわかりました。プールをアカウントをまたいで共有したり、CIDRを切り出して別のアカウントに移譲もできるので、大規模な環境で自社のIPアドレスをクラウドで使うのも現実的そうだと感じました。
今年からAWS提供のパブリックIPv4アドレスが有償化されたので、(IPv6の適用を拡大しつつ)自前のIPv4アドレスを持ち込んで利用することでコスト削減につながるかもしれません。
AWSのパブリックIPv4の料金体系の変更とサイバーエージェントのIPv6活用推進事例
本当はBYOASNも試したいのですがJPNICに対応していないため、何かしら対応できる方法が今後出てくるといいなと思います。また、Google CloudもJPNIC割当のIPアドレスでBYOIPできるようになると同じIPアドレスを複数のクラウドから広報でき、実用性はともかく「マルチクラウド」っぽい遊びもできるかもしれません。
2407:a6c0:318:ca:318:ca:318:ca のEC2インスタンスは今日から一週間くらいは置いておこうと思うのでpingの確認などにご利用ください。