コンテナ データセンターで AS 取ってみた


2021/03 末に APNIC から ASN と IPv4 /23、IPv6 /48 を個人として割り当てを受けました。
半年近くかかってしまいましたが、ようやく Internetable になったのでメモ程度ですが書き残しておきます。

1. データセンターを建設します

月日が経つのは早いもので、コンテナ用地を競売で取得してから既に 5 年ほど経ちました。
一般のご家庭でサーバーやネットワーク機器を稼働させると騒音やら夏場の室温やら床の耐荷重が気になるので、
若いうち ( 家庭内稟議とかいう面倒な制度が導入される前) にデータセンターを 1 つ建てておくといいと思います。

この記事を読んでいる方には今更かと思いますが、過去の投稿や記事もご参考にどうぞ。

2. やる気を発掘します

これが一番大変。Twitter を遡ってみた限り、2015/02 (新卒 2 年目、コンテナ建設前) には AS が欲しいと言っていたようです。
まさか重い腰を上げるのに 6 年半前もかかっていたとは…。
AS 欲しいと言うたびに煽っていただいたり、有用な情報をいただいた界隈の皆様には改めて感謝です。

3. フルルートが食える機器を確保します

2021/08 時点では、EOL を迎えた ASR 1001 にメモリを増設するのが安くすむ気がしました。
いずれは ASR 1001-X とか MX204 にも手を出したいけど、高くて気軽には買えないので…。

他にもいい機種があったら教えてください。

4. JPNIC / APNIC 等に申請します

JPNIC / APNIC の関連ドキュメントを隅から隅まで熟読しましょう。
私は AS が欲しいと思ったタイミングで毎回読んでいたので、10 回くらい (多少盛ってる?) は読んだ気がします。

JPNIC と APNIC のどちらで申請するかはお好みで。
費用的には JPNIC の方が安く済みそうでしたが、英語の練習と諸々の理由で私は APNIC にしました。

APNIC の申請については、SDCC のスライドを参考にさせていただきました。

5. Transit を確保します

2020/10 に開催された CEATEC の講演の中で、登さんが IPA に機材を送るとフルルートがもらえるという噂が… (47:30 頃)
なんて話をされていたので、弊コンテナも Transit の提供をお願いしました。
ソフトイーサの皆様、改めてありがとうございます。

ちなみに、昨今だと BYOIP (Bring Your Own IP) できるクラウドも増えてきているので、それはそれで遊んでみたいと思います。
Azure も早く BYOIP できるようにならないかな…。

6. DNS の逆引き設定をします

APNIC の場合、 逆引きの委任は Resource Manager – Whois Updates – Add から domain Object を選択し、
フォームを埋めるだけで完了するようです。

弊コンテナでは、とりあえず Azure DNS で逆引きゾーンをホストする形にしました。
委任後の Azure DNS 側の設定は、以下のドキュメントとかを適当に参照しつつ、PTR レコードを作れば良さそう。
DNS 周りは誤って削除すると事故になりがちなので、リソースの削除ロックも設定しています。

7. To be Continued…

夏休み中に内部の構成まで終わらせるつもりだったんですが、残念ながら時間切れ…。
進捗があったら、また気まぐれで追記するかもしれません。


トリシティにドライブレコーダー付けた


珍しく仕事絡みじゃないブログです。

TRICITY 155 にミツバサンコーワのドライブレコーダー EDR-21G をつけたんですが、専用アプリを使わずに PC からファイルをダウンロードしたかったので、軽く調べてみました。(というのも、いちいちカバーを外さないと microSD の抜き差しができない位置にドラレコの本体をつけられてしまったようで…。)

多分、同じシリーズで 1 カメラだけの EDR-11 とか、2 カメラで GPS 無しの EDR-21 でもいける気がします。

なお、メーカーが公表している使用方法じゃないので、あくまでも自己責任で、間違ってもメーカーには問い合わせないように。

https://www.mskw.co.jp/motorcycle/edr/

とりあえず、まずは専用アプリをインストールして使おうと思ったら、ものすごく評判が悪い。

普通にドラレコ自身の Wi-Fi AP に接続したうえでアプリを使えばいいだけなんだけど、どうやら自宅の無線とか拾って繋がらないと言っている人が多い模様。(Google Play ストア上も、Web サイト上も、FAQ を参照するように強調されてたので、Android 側でインターネット接続できる AP に自動的に切り替えちゃうせいでメーカーに繋がらないって問い合わせが多い模様…?)

※ 以下、公式サイトより画像抜粋

専用アプリで雰囲気を理解したところで、PC から Wi-Fi で繋いで IP を確認すると、192.168.1.0/24 の IP が降ってきます。(DHCP では 192.168.1.33 以降が降ってくるようでした。)

そのまま適当に 192.168.1.0/24 に Ping を飛ばして ARP テーブルを見てみると、どうやら 192.168.1.254 がドラレコっぽいことがわかります。(機種とかファームによって違うかも。知らんけど。)

ブラウザから http://192.168.1.254 にアクセスしてみると、普通にファイルの一覧が出てきてダウンロードできたので、あっさり解決。ファイル名の F がフロント側、R がリア側みたいですね。

専用アプリ無しで PC から扱えそうなことが分かったので、それ以上はあまり調べてませんが、レスポンスの内容を見ていると Server: hfs 1.00.000 とか帰ってきていて、HTTP File Server 的なものが動いている模様。ほかにも 443 / 3333 / 8192 あたりが Listen してそうな気配がありました。

ご参考まで。


GatewaySubnet のサイズについて


Azure で VPN や ExpressRoute を利用する場合、VNet Gateway を配置するための GatewaySubnet を用意する必要があります。この GatewaySubnet のサイズについて、たまに聞かれることがあるので要点だけメモしておきます。

結論から言うと /27 より大きいアドレス空間で作成することが推奨です。(大規模環境に限って、後述の通り /26 が必要です。)

必要最小限という意味では、以下の通りになります。

  • VPN のみの場合: /29
  • ExpressRoute のみの場合: /28
  • VPN / ExpressRoute を併用する場合: /27

ただ、あとから VPN と ExpressRoute の共存構成にする場合なども多々あるため、事前に /27 で作成しておくことを強く推奨します。
(クラウドは機能拡張や仕様変更が頻繁に発生するのが常なので、将来の予期せぬ事態に備えて /24 くらいあると更に安心ですかね…。)

当初は VPN だけ (ないし、ExpressRoute だけ) 使っていて、あとから併用することになった場合、既存の Gateway を削除して GatewaySubnet 内を空にしてからでないと GatewaySubnet のサブネットを拡張できません。つまり、事前に小さなサブネットで作成してしまっていると、構成変更時に通信断が必ず発生する事になります。そのため、/27 か、それよりも大きいアドレス空間での作成が推奨されています。

# 2021/07/20 追記
1 つの VNet に接続できる ExpressRoute 回線が、以前は 4 本まででしたが、SKU によっては最大 16 本まで拡張されました。これに伴って、多数の ExpressRoute 回線を接続する場合に限り /27 では不足するため、/26 が必要な場合がありますのでご注意ください。

同じピアリング場所で同じ仮想ネットワークにリンクされる ExpressRoute 回線の最大数4
さまざまなピアリング場所で同じ仮想ネットワークにリンクされる ExpressRoute の最大数16 (詳細については、「ゲートウェイの SKU」を参照してください。)

ゲートウェイに 16 本の ExpressRoute 回線を接続するつもりであれば、/26 以上のゲートウェイ サブネットを作成する 必要があります


ExpressRoute 回線の転送量の算出方法


ExpressRoute の直近 1 日とか 1 週間の通信量を確認したい場合は、NPM を有効化して Log Analytics のクエリを使うと便利です。

NPM を有効化していない方は、まず以下のドキュメントの通り設定しましょう。

NPMを有効化して ExpressRoute 回線の監視を有効化しておくと、Log Analytics の [Network Performance Monitor] – [NetworkMonitoring] というテーブルにログが記録されるようになりますので、以下の様なクエリで期間内の値を合算することで転送量が取得できます。Log Analytics の画面上部で対象となる期間 (時間の範囲) を指定し、クエリ内のリソース URI の箇所だけ適宜変えて使ってください。

(送受信)

NetworkMonitoring
| where (SubType == "ERCircuitTotalUtilization") and CircuitResourceId == "/subscriptions/<Subscription ID>/resourceGroups/<RG name>/providers/Microsoft.Network/expressRouteCircuits/<ER Name>"
| extend BitsTotalPerSecond = BitsInPerSecond + BitsOutPerSecond
| summarize sum(BitsTotalPerSecond)

(受信のみ)

NetworkMonitoring
| where (SubType == "ERCircuitTotalUtilization") and CircuitResourceId == "/subscriptions/<Subscription ID>/resourceGroups/<RG name>/providers/Microsoft.Network/expressRouteCircuits/<ER Name>"
| summarize sum(BitsInPerSecond)

(送信のみ)

NetworkMonitoring
| where (SubType == "ERCircuitTotalUtilization") and CircuitResourceId == "/subscriptions/<Subscription ID>/resourceGroups/<RG name>/providers/Microsoft.Network/expressRouteCircuits/<ER Name>"
| summarize sum(BitsOutPerSecond )

あと、1 ヶ月分を 1 日単位で集計したい等という場合には、期間を 1 ヶ月にした上で、以下の様にクエリに少し足すと 1 日単位での集計にしたりもできます。

 | summarize sum(BitsTotalPerSecond) by bin(TimeGenerated, 1d) 

[Day8] やってはいけない DNS サーバーの参照設定


# Microsoft Azure Tech Advent Calendar 2019 の 8 日目です。

Azure に限った話ではないですが、DNS サーバーの参照設定を誤っている人が多いので、注意喚起の意味を込めて。

この設定を見て、何がおかしいか分かりますか?

上図では、 外部用の DNS サーバー (Google Public DNS) と、内部用の DNS サーバー (AD DC 兼 DNS サーバー) を参照する設定になっています。設定者の意図としては、パブリックな名前解決は前者で、 イントラの名前解決は後者で行われることを期待して、こうした誤った設定が行われていることが多いですが、実際にはそのようには機能しません。

実際にイントラ向けの名前解決をしてみると、以下のように優先 DNS サーバーに設定された Google の Public DNS サーバーに問い合わせたものの、Non-existent domain (NXDOMAIN) がかえってきて名前解決に失敗するかと思います。

これは何故かというと、Primary DNS サーバーに設定された Google Public DNS は、社外に公開されていないイントラのゾーン (intra.contoso.local 等) を知りえないからです。Windows OS の DNS クライアント (スタブリゾルバ) としては、エラーを受け取った時点で名前解決は失敗したものとして扱いますので、Secondary DNS サーバーに対して名前解決は試行されません。

では、どのように設定するのが正しいかというと、クライアント端末にはイントラの名前解決ができる内部向けの DNS サーバーを参照させましょう。

そして、参照先の DNS サーバー (AD 兼 DNS サーバー等) においてフォワーダーやルートヒントで外部の名前解決を行えるようにすれば、自身が管理していない外部の名前解決はフォワーダーやルートヒントを利用して行ってくれるようになります。

念のため、[再帰を無効にする] がチェックされていないことも確認しましょう。

これで、外部・内部ともに正常に名前解決が行えるようになったかと思います。

P.S. Azure VM の場合は、OS 内の NIC の設定で参照先の DNS サーバーを指定するのではなく、Azure VNet や Azure としての NIC の設定 (つまり、Azure Portal ) で DNS サーバーを指定しましょう。(OS 内の NIC の設定は触らないのが原則です。)


ExpressRoute の SKU と機能の差異について


ExpressRoute と名の付くサービスが増えてきたので、SKU 毎の機能差をまとめておこうと思います。
(以下は 2019/11 現在の情報に基づきます。)

3 種類の ExpressRoute サービス

  • ExpressRoute Circuit (ExpressRoute 回線):
    接続プロバイダーを介して Azure と 50Mbps – 10Gbps で閉域接続するサービス
    (普通は ExpressRoute といったらこれ)
  • ExpressRoute Global Reach:
    2 つの ExpressRoute 回線を介して、オンプレミス間を接続するサービス
    (例えば、東京・大阪で ExpressRoute 回線を 1 つずつ用意すれば、東阪間を MS Backbone 経由で行える)
  • ExpressRoute Direct:
    Azure のエッジルーターと 10Gbps / 100Gbps で直接接続するサービス
    (要個別申請&国内で提供されているのか不明)

各 SKU の概要

  • ExpressRoute Standard:
    ER の接続場所と同一地域のリージョンにのみ接続可能
    (例えば ER を東京で契約した場合、東日本・西日本リージョンのみに接続可能)
  • ExpressRoute Premium:
    世界中のリージョンに接続可能
    (ER を東京で契約していても、米国や欧州のリージョンにも接続可能)
  • ExpressRoute Local (最低 1Gbps からの提供):
    ER の接続場所の最寄のリージョンにのみ接続可能な代わりに、送信データ転送に関する課金なし
    (ER を東京で契約した場合、東日本リージョンのみ接続可能)
    # 1Gbps の無制限からだと結構なお値段なので、あえて選ぶメリットあんまりないかな…

Standard / Premium の違い

SKUStandardPremium
価格安い高い
接続可能リージョン接続した場所と同一地域世界中の Azure リージョン
Private Peering での経路上限400010000
接続できる VNet 上限1020 – 100 (帯域次第)

PaaS のサービス等で、海外リージョンへの接続性が必要になることも多いので、悩んだら Premium SKU を使っておけばいいと思います。