Network, Windows Azure / Microsoft Azure, コンテナ データセンター

Azure で BYOIP を試してみる

by  •  • 0 Comments

# Microsoft Azure Tech Advent Calendar 2022 の 17 日目です。

2022 年 4 月から、Azure においても BYOIP (Bring your own IP) ができるようになりました。
ただ、気軽に試せるものではないので、私が個人で運用している AS / Public IP で検証した際の記録を書き残しておこうと思います。

BYOIP とは

Azure の Public IP アドレスとして、自社 (自 AS) が APNIC 等から割り当てを受けた Public IP アドレスを持ち込むことができます。
そのため、例えば以下のようなシナリオにおいてメリットがあります。

  • オンプレミスで動かしていたサーバーを Azure へ移行する際に、Public IP アドレスを変更せずに移行できる
  • 自社専用の Public IP アドレス レンジを確保できるため、Firewall 等で許可する IP アドレスの管理が容易になる
  • 誤って Public IP アドレスのリソースを削除しても他者に利用される事が無く、再度同一の Public IP アドレスを採番できる

なお、2 点目と 3 点目に関しては、パブリック IP プレフィックスでも同様のメリットを享受できます。
ほとんどの方は、BYOIP ではなく、パブリック IP プレフィックスで十分かと思います。

BYOIP を利用するための前提条件

まずは公式ドキュメント (英語版推奨) に隅から隅まで目を通していただければと思いますが、ポイントとしては以下の 3 点です。

  • ARIN / RIPE NCC / APNIC から AS 番号および Public IP アドレスの割り当てを受けている事 (LACNIC / AFRINIC は要相談らしい)
  • Origin AS を 8075 (Microsoft) とした ROA を作成すること
  • BYOIP で持ち込む Public IP アドレスは、IPv4 の場合 /24 以上であること (/25 以下は不可)

/24 より小さい Public IP レンジを持ち込めないのは何故？

普段から AS の運用に携わっている方々であれば、当たり前に (もしくは、暗黙的に) ご存じな部分かと思いますが、
(ネットワーク エンジニアであっても) AS 運用をしたことのない人にはピンとこないと思うので、少しだけ補足です。

BYOIP を利用すると、Microsoft の AS8075 から Internet (MS と Peer している多数の AS) に対して BGP で経路を広報します。
ただ、Internet の世界では多くの AS が /24 より細かい (具体的な) 経路は受け取らないようにフィルターしてることが一般的です。
このため、Azure の BYOIP 固有の制限という訳ではなく、Internet の世界のお作法として /24 が最小ということになっており、
それより小さい Public IP アドレス レンジを Azure に持ち込むといったことは出来ません。
RFC 7454 にて明文化されているようでしたので、ご興味があればそちらも併せてご覧ください。

6.1.3. Prefixes That Are Too Specific
Most ISPs will not accept advertisements beyond a certain level of specificity (and in return, they do not announce prefixes they consider to be too specific). That acceptable specificity is decided for each peering between the two BGP peers. Some ISP communities have tried to document acceptable specificity. This document does not make any judgement on what the best approach is, it just notes that there are existing practices on the Internet and recommends that the reader refer to them. As an example, the RIPE community has documented that, at the time of writing of this document, IPv4 prefixes longer than /24 and IPv6 prefixes longer than /48 are generally neither announced nor accepted in the Internet [20] [21]. These values may change in the future.

逸般の誤家庭にある AS で試してみる

それでは、どこのご家庭にもある AS で BYOIP を試していきましょう。

まずは公式ドキュメントの手順に従って証明書の準備を行います。
openssl + PowerShell なのが違和感ありますが、ドキュメントに書かれている通りに証明書を作成しましょう。

./openssl genrsa -out byoipprivate.key 2048
Set-Content -Path byoippublickey.cer (./openssl req -new -x509 -key byoipprivate.key -days 180) -NoNewline

次に、上記で生成した byoippublickey.cer の内容を Whois/RDAP のパブリック コメントとして登録します。
私の AS38215 は APNIC から割り当てを受けていますので、APNIC の管理画面 (Resource Manager) から行います。
[Whois Updates] – [Update] から、inetnum (IPv6 の場合は inet6num) を選択して対象のオブジェクトを検索します。

対象の object が表示されたら、最下部で [remarks] のフィールドを追加し、byoippublickey.cer の内容を張り付けて [Update] します。
その他のフィールドについては、特に変更せずそのままにしておきましょう。

次に、AS8075 を Origin AS とした ROA を作成していきます。
通常は以下のように自 AS を Origin とした ROA が作成されている状態かと思いますが、[Add new] から追加をします。

今回は、APNIC から割り当てられた /23 のうち、103.164.237.0/24 だけを Azure に持ち込むので以下のように作成しています。

しばらく待つと、ROA status と Whois status がともに EXISTS になったことが確認できます。

続いて、Azure 側で BYOIP リソースを作成する際に必要な署名付きメッセージを生成します。

$byoipauth=”xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx|1.2.3.0/24|yyyymmdd”
Set-Content -Path byoipauth.txt -Value $byoipauth -NoNewline
./openssl dgst -sha256 -sign byoipprivate.key -keyform PEM -out byoipauthsigned.txt byoipauth.txt
$byoipauthsigned=(./openssl enc -base64 -in byoipauthsigned.txt) -join ”

上記で生成した署名付きメッセージ ($byoipauthsigned) を用いて、Azure Portal でカスタム IP プレフィックスのリソースを作成します。
ROA の有効期限については、APNIC だと該当する欄が見当たらなかったため、仮で未来の日付を設定しています。

正常にリソースが作成されたら、初期状態では [委任状態] が [Provisioning] になっているかと思います。
公式ドキュメントによると、3-4 時間以内に委任プロセスが完了するとされていますので、しばらく待ちましょう。
何らか問題があった場合には、[Failed Reason] の欄にエラーになった原因が表示されます。

プロビジョニングが完了すると、持ち込んだアドレス (カスタム IP プレフィックス) からパブリック IP プレフィックスを作成できます。

更に、パブリック IP プレフィックスからパブリック IP アドレスのリソースを切り出して、VM 等に紐付けて使いましょう。
(この時点ではまだ Internet に経路が広報されていないため、Azure への疎通性はありません。)

最後に、[委任] を行って数時間待ち、[委任状態] が [Commissioned] になれば完了です。

Looking Glass 等で AS8075 から Internet に経路が広報されたことを確認後、オンプレミス側で当該 Prefix の経路広報を停止します。
(オンプレミスと Azure の双方から経路を広報してしまうと、正しく通信できなくなる恐れがあるので気をつけましょう。)

(参考)

Query Results:
Router: Tokyo – JP
Command: show bgp ipv4 unicast 103.164.237.0/24

BGP routing table entry for 103.164.237.0/24
Versions:
Process bRIB/RIB SendTblVer
Speaker 812761006 812761006
Last Modified: Dec 2 08:42:32.006 for 02:32:01
Paths: (32 available, best #29)
Advertised IPv4 Unicast paths to update-groups (with more than one peer):
0.2 0.4 0.8 0.15 0.22
Advertised IPv4 Unicast paths to peers (in unique update groups):
198.64.4.116 219.158.1.130 219.158.1.151 210.173.174.178
219.158.1.153 210.173.174.170 61.120.145.110 61.120.145.206
Path #1: Received by speaker 0
Not advertised to any peer
3257 8075
77.67.120.41 (metric 40110) from 129.250.0.6 (129.250.0.6)
Origin IGP, metric 4294967294, localpref 100, valid, confed-internal
Received Path ID 0, Local Path ID 0, version 0
Community: 2914:390 2914:1214 2914:2213 2914:3200 3257:3257 65504:3257
Path #2: Received by speaker 0
Not advertised to any peer
7018 8075
192.205.32.193 (metric 17056) from 129.250.0.9 (129.250.0.9)
Origin IGP, metric 4294967294, localpref 100, valid, confed-internal
Received Path ID 0, Local Path ID 0, version 0
Community: 2914:390 2914:1003 2914:2000 2914:3000 65504:7018
Path #3: Received by speaker 0
Not advertised to any peer
1299 8075
129.250.66.38 (metric 19430) from 129.250.0.20 (129.250.0.20)
Origin IGP, metric 4294967294, localpref 100, valid, confed-internal
Received Path ID 0, Local Path ID 0, version 0
Community: 2914:390 2914:1011 2914:2000 2914:3000 65504:1299
Path #4: Received by speaker 0
Not advertised to any peer
1299 8075
129.250.8.62 (metric 17057) from 129.250.0.21 (129.250.0.21)
Origin IGP, metric 4294967294, localpref 100, valid, confed-internal
Received Path ID 0, Local Path ID 0, version 0
Community: 2914:390 2914:1003 2914:2000 2914:3000 65504:1299
Path #5: Received by speaker 0
Not advertised to any peer
3257 8075
77.67.98.53 (metric 30610) from 129.250.0.31 (129.250.0.31)
Origin IGP, metric 4294967294, localpref 100, valid, confed-internal
Received Path ID 0, Local Path ID 0, version 0
Community: 2914:390 2914:1203 2914:2201 2914:3200 3257:3257 65504:3257
Path #6: Received by speaker 0
Not advertised to any peer
3257 8075
46.33.78.153 (metric 40130) from 129.250.0.38 (129.250.0.38)
Origin IGP, metric 4294967294, localpref 100, valid, confed-internal
Received Path ID 0, Local Path ID 0, version 0
Community: 2914:390 2914:1210 2914:2210 2914:3200 3257:3257 65504:3257
Path #7: Received by speaker 0
Not advertised to any peer
1299 8075
129.250.8.46 (metric 36615) from 129.250.0.46 (129.250.0.46)
Origin IGP, metric 4294967294, localpref 100, valid, confed-internal
Received Path ID 0, Local Path ID 0, version 0
Community: 2914:390 2914:1219 2914:2204 2914:3200 65504:1299
Path #8: Received by speaker 0
Not advertised to any peer
1299 8075
129.250.9.22 (metric 19422) from 129.250.0.48 (129.250.0.48)
Origin IGP, metric 4294967294, localpref 100, valid, confed-internal
Received Path ID 0, Local Path ID 0, version 0
Community: 2914:390 2914:1002 2914:2000 2914:3000 65504:1299
Path #9: Received by speaker 0
Not advertised to any peer
1299 8075
62.115.147.64 (metric 34110) from 129.250.0.72 (129.250.0.72)
Origin IGP, metric 4294967294, localpref 100, valid, confed-internal
Received Path ID 0, Local Path ID 0, version 0
Community: 2914:390 2914:1201 2914:2202 2914:3200 65504:1299
Path #10: Received by speaker 0
Not advertised to any peer
1299 8075
62.115.162.70 (metric 30610) from 129.250.0.75 (129.250.0.75)
Origin IGP, metric 4294967294, localpref 100, valid, confed-internal
Received Path ID 0, Local Path ID 0, version 0
Community: 2914:390 2914:1203 2914:2201 2914:3200 65504:1299
Path #11: Received by speaker 0
Not advertised to any peer
1299 8075
213.248.81.62 (metric 20046) from 129.250.0.82 (129.250.0.82)
Origin IGP, metric 4294967294, localpref 100, valid, confed-internal
Received Path ID 0, Local Path ID 0, version 0
Community: 2914:390 2914:1006 2914:2000 2914:3000 65504:1299
Path #12: Received by speaker 0
Not advertised to any peer
3257 8075
199.229.229.201 (metric 19422) from 129.250.0.85 (129.250.0.85)
Origin IGP, metric 4294967294, localpref 100, valid, confed-internal
Received Path ID 0, Local Path ID 0, version 0
Community: 2914:390 2914:1002 2914:2000 2914:3000 3257:3257 65504:3257
Path #13: Received by speaker 0
Not advertised to any peer
1299 8075
213.248.70.12 (metric 12263) from 129.250.0.87 (129.250.0.87)
Origin IGP, metric 4294967294, localpref 100, valid, confed-internal, group-best
Received Path ID 0, Local Path ID 0, version 0
Community: 2914:390 2914:1007 2914:2000 2914:3000 65504:1299
Path #14: Received by speaker 0
Not advertised to any peer
1299 8075
129.250.9.70 (metric 37610) from 129.250.0.97 (129.250.0.97)
Origin IGP, metric 4294967294, localpref 100, valid, confed-internal
Received Path ID 0, Local Path ID 0, version 0
Community: 2914:390 2914:1215 2914:2214 2914:3200 65504:1299
Path #15: Received by speaker 0
Not advertised to any peer
3257 8075
212.222.122.89 (metric 37610) from 129.250.0.104 (129.250.0.104)
Origin IGP, metric 4294967294, localpref 100, valid, confed-internal
Received Path ID 0, Local Path ID 0, version 0
Community: 2914:390 2914:1215 2914:2214 2914:3200 3257:3257 65504:3257
Path #16: Received by speaker 0
Not advertised to any peer
1299 8075
62.115.144.98 (metric 34115) from 129.250.0.119 (129.250.0.119)
Origin IGP, metric 4294967294, localpref 100, valid, confed-internal
Received Path ID 0, Local Path ID 0, version 0
Community: 2914:390 2914:1212 2914:2212 2914:3200 65504:1299
Path #17: Received by speaker 0
Not advertised to any peer
1299 8075
129.250.8.17 (metric 18110) from 129.250.0.133 (129.250.0.133)
Origin IGP, metric 4294967294, localpref 100, valid, confed-internal
Received Path ID 0, Local Path ID 0, version 0
Community: 2914:390 2914:1001 2914:2000 2914:3000 65504:1299
Path #18: Received by speaker 0
Not advertised to any peer
1299 8075
62.115.156.248 (metric 16257) from 129.250.0.142 (129.250.0.142)
Origin IGP, metric 4294967294, localpref 100, valid, confed-internal
Received Path ID 0, Local Path ID 0, version 0
Community: 2914:390 2914:1004 2914:2000 2914:3000 65504:1299
Path #19: Received by speaker 0
Not advertised to any peer
1299 8075
129.250.8.230 (metric 18110) from 129.250.0.166 (129.250.0.166)
Origin IGP, metric 4294967294, localpref 100, valid, confed-internal
Received Path ID 0, Local Path ID 0, version 0
Community: 2914:390 2914:1009 2914:2000 2914:3000 65504:1299
Path #20: Received by speaker 0
Not advertised to any peer
12956 8075
213.140.53.50 (metric 27676) from 129.250.0.170 (129.250.0.170)
Origin IGP, metric 4294967294, localpref 100, valid, confed-internal, group-best
Received Path ID 0, Local Path ID 0, version 0
Community: 2914:390 2914:1601 2914:2601 2914:3600 12956:123 12956:4002 12956:4020 12956:15550 12956:19644 65504:12956
Path #21: Received by speaker 0
Not advertised to any peer
1299 8075
62.115.12.52 (metric 12263) from 129.250.0.178 (129.250.0.178)
Origin IGP, metric 4294967294, localpref 100, valid, confed-internal
Received Path ID 0, Local Path ID 0, version 0
Community: 2914:390 2914:1008 2914:2000 2914:3000 65504:1299
Path #22: Received by speaker 0
Not advertised to any peer
1299 8075
129.250.9.14 (metric 30615) from 129.250.0.180 (129.250.0.180)
Origin IGP, metric 4294967294, localpref 100, valid, confed-internal
Received Path ID 0, Local Path ID 0, version 0
Community: 2914:390 2914:1205 2914:2204 2914:3200 65504:1299
Path #23: Received by speaker 0
Not advertised to any peer
8075
128.241.8.231 (metric 12222) from 129.250.0.186 (129.250.0.186)
Origin IGP, metric 100, localpref 120, valid, confed-internal, import-candidate
Received Path ID 0, Local Path ID 0, version 0
Community: 2914:370 2914:375 2914:1405 2914:2406 2914:3400 2914:3475
Path #24: Received by speaker 0
Not advertised to any peer
3257 8075
46.33.83.249 (metric 34110) from 129.250.0.190 (129.250.0.190)
Origin IGP, metric 4294967294, localpref 100, valid, confed-internal
Received Path ID 0, Local Path ID 0, version 0
Community: 2914:390 2914:1206 2914:2203 2914:3200 3257:3257 65504:3257
Path #25: Received by speaker 0
Not advertised to any peer
1299 8075
129.250.8.50 (metric 34110) from 129.250.0.194 (129.250.0.194)
Origin IGP, metric 4294967294, localpref 100, valid, confed-internal
Received Path ID 0, Local Path ID 0, version 0
Community: 2914:390 2914:1206 2914:2203 2914:3200 65504:1299
Path #26: Received by speaker 0
Not advertised to any peer
7018 8075
129.250.9.62 (metric 12262) from 129.250.0.198 (129.250.0.198)
Origin IGP, metric 4294967294, localpref 100, valid, confed-internal, group-best
Received Path ID 0, Local Path ID 0, version 0
Community: 2914:390 2914:1005 2914:2000 2914:3000 65504:7018
Path #27: Received by speaker 0
Not advertised to any peer
1299 8075
213.248.103.170 (metric 13799) from 129.250.0.236 (129.250.0.236)
Origin IGP, metric 4294967294, localpref 100, valid, confed-internal
Received Path ID 0, Local Path ID 0, version 0
Community: 2914:390 2914:1005 2914:2000 2914:3000 65504:1299
Path #28: Received by speaker 0
Not advertised to any peer
3257 8075
129.250.8.22 (metric 18110) from 129.250.1.11 (129.250.1.11)
Origin IGP, metric 4294967294, localpref 100, valid, confed-internal, group-best
Received Path ID 0, Local Path ID 0, version 0
Community: 2914:390 2914:1001 2914:2000 2914:3000 3257:3257 65504:3257
Path #29: Received by speaker 0
Advertised IPv4 Unicast paths to update-groups (with more than one peer):
0.2 0.4 0.8 0.15 0.22
Advertised IPv4 Unicast paths to peers (in unique update groups):
198.64.4.116 219.158.1.130 219.158.1.151 210.173.174.178
219.158.1.153 210.173.174.170 61.120.145.110 61.120.145.206
8075
128.241.8.227 (metric 11027) from 129.250.1.14 (129.250.1.14)
Origin IGP, metric 100, localpref 120, valid, confed-internal, best, group-best, import-candidate
Received Path ID 0, Local Path ID 1, version 812761006
Community: 2914:370 2914:375 2914:1409 2914:2403 2914:3400 2914:3475
Path #30: Received by speaker 0
Not advertised to any peer
7018 8075
192.205.37.57 (metric 12262) from 129.250.1.40 (129.250.1.6)
Origin IGP, metric 4294967294, localpref 100, valid, confed-internal
Received Path ID 0, Local Path ID 0, version 0
Community: 2914:390 2914:1008 2914:2000 2914:3000 65504:7018
Originator: 129.250.1.6, Cluster list: 129.250.1.40
Path #31: Received by speaker 0
Not advertised to any peer
7018 8075
192.205.37.57 (metric 12262) from 129.250.1.41 (129.250.1.6)
Origin IGP, metric 4294967294, localpref 100, valid, confed-internal
Received Path ID 0, Local Path ID 0, version 0
Community: 2914:390 2914:1008 2914:2000 2914:3000 65504:7018
Originator: 129.250.1.6, Cluster list: 129.250.1.41
Path #32: Received by speaker 0
Not advertised to any peer
7018 8075
192.205.37.57 (metric 12262) from 129.250.1.42 (129.250.1.6)
Origin IGP, metric 4294967294, localpref 100, valid, confed-internal
Received Path ID 0, Local Path ID 0, version 0
Community: 2914:390 2914:1008 2914:2000 2914:3000 65504:7018
Originator: 129.250.1.6, Cluster list: 129.250.1.42

補足 (2024/01 時点の情報)

JPNIC から割り当てられた AS / Public IP の場合、JPNIC の Whois では inetnum / inet6num で remarks が使えないようなので、BYOIP は不可のようです。(Azure に限らず、AWS 等も同様の仕組みを使ってプロビジョニングするようなので、同じく BYOIP 不可と思われます。)

BYOIP したい方は、当面は APNIC 等から新規で割り当てをもらうしかなさそうです。

PowerShell, Windows Azure / Microsoft Azure

NSG Flow Log を Azure PowerShell で扱いたい

by  •  • 0 Comments

NSG Flow Log を Azure Storage にエクスポートしておいても、JSON のままだと解析が難しいので Tuple (IP / Port, etc…) だけ簡単に抽出できる PowerShell を書いてみました。

Traffic Analytics を有効化して Log Analytics で Kusto クエリを使う方がおすすめですが、有効化し忘れてて JSON を生で見るしか無い時などで使ってみてください。ログの量が多いと非常に時間がかかるので、適当に条件追加してフィルターしたりしていただければと。

# 各種パラメーター (要変更)
$ResourceGroupName = "RG-Name"
$StorageName = "StrName"
$LogPath = "C:\Users\UserName\Desktop\NsgFlowLog\"    # 作成済みのフォルダを指定、末尾に \ が必要
$ResultPath = "C:\Users\UserName\Desktop\NsgFlowLog\"     # 同上

# Azure Storage へのアクセス用の認証情報を取得
$StorageAccount = Get-AzStorageAccount -ResourceGroupName $ResourceGroupName -Name $StorageName
$Context = $StorageAccount.Context

# Blob から NSG フロー ログをダウンロード
Get-AzStorageBlob -Container "insights-logs-networksecuritygroupflowevent" -Context $Context | Get-AzStorageBlobContent -Destination $LogPath

# ファイル一覧を取得
$FileList = Get-ChildItem -Path $LogPath -include *.json -Recurse -Force 

# NSG フローログから flowTuples のみを抽出
$Records = @("Time Stamp,Source IP,Destination IP,Source Port,Destination Port,Protocol,Traffic Flow,Traffic Decision,Flow State,Packets - Source to destination,Bytes sent - Source to destination,Packets - Destination to source,Bytes sent - Destination to source")
$Records += $FileList | foreach {(Get-Content -Path $_.FullName | ConvertFrom-Json).records.properties.flows.flows.flowtuples}

# 全てのレコードを抽出して CSV ファイルを生成
$Records | Out-File "$ResultPath\AllRecords.csv" -Encoding utf8

# 特定の条件を満たすレコードを抽出して CSV ファイルを生成 ("O,D" すなわち Outbound で Deny されたものだけ抽出する場合)
$Records | Select-String "O,D" | Out-File "$ResultPath\FilteredRecords.csv" -Encoding utf8

# 特定の条件を満たすレコードを抽出して画面表示
$CSV = ($Records | ConvertFrom-Csv)
$CSV | where {$_."Destination Port" -eq 443 -and $_."Traffic Flow" -eq "O"} | Format-Table

なお、NSG Flow Log のログ フォーマットについては、以下のドキュメントに記載があります。TCP は “T”、UDP は “U”、Inbound は “I”、Outbound は “O”、Allow は “A”、Deny は “D” といった感じなので、特に難しくは無いと思いますが、フィルターする文字列はログ フォーマットを読みつついじってください。

※ Windows ではファイル パスが 260 文字の制約があるので、ダウンロード フォルダは C ドライブ直下などにする事を推奨します。

Windows Azure / Microsoft Azure, コンテナ データセンター

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

by  •  • 0 Comments

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

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

by  •  • 0 Comments

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

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 してそうな気配がありました。

ご参考まで。

Network, VPN, Windows Azure / Microsoft Azure

GatewaySubnet のサイズについて

by  •  • 0 Comments

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 以上のゲートウェイ サブネットを作成する 必要があります。