IoTセンサーをVPNの内側に置く前に決める三つのアドレス

IoTをVPN越しにつなぐ計画では、三つのアドレスが絡み合いますが、同じ種類の判断ではありません。一つは遠隔の運用者がトンネルの終端をどう見つけるか、一つは拠点が自分自身であることをどう証明するか、もう一つはセンサーのサービスが実際どこで待ち受けるかです。この順に答えれば、設計はおおむね自然に決まります。一つの問いにまとめて答えると、必要のなかった機器に公開アドレスを与えることになります。外向きの拠点トンネルの内側にあるセンサーは、センサー宛ての受信ルールが一つもなくても、権限のある運用者から到達できます。

まず誰が接続を始めるかを決める

どちらから接続するかで、後段のほぼすべてが決まります。拠点からハブへ接続する場合、拠点には受信の到達性が不要で、ハブには拠点が解決できる名前かアドレスが必要です。この一つの選択だけで、静的な公開アドレスをめぐる議論の大半が始まる前に消えます。

そうすると三つの役割はきれいに分かれ、下の表が判断の最短形です。

各行の所有者は異なり、そこが本当の要点です。ハブはVPNサービスを運用する人のもの、拠点ピアはネットワークチームのもの、センサーのアドレスは機器を所有する人のものです。

ハブのアドレスは起動用であり、到達先ではない

維持された公開アドレスに解決する名前でハブには十分です。DNSレコードは終端が移動しても追随でき、拠点の設定を一つずつ手で書き換える必要はありません。DNSがしないのは到達性を作ることと、古い応答をキャッシュしたクライアントを更新することであり、これらは別々の問題で別々の対処が必要です。

ハブを置かずに拠点間トンネルを運用する場合も、片側に到達可能な終端が必要か、両側が第三者に接続するかという同じ論理が別の形で成り立ちます。そのアドレスと更新の責任者は、どちらにせよ必要です。

拠点ピアはプレフィックスが付いた識別情報

ピアはまず識別情報で、次にプレフィックスです。WireGuardの用語では、ピアが鍵ペアを保持し、ハブの AllowedIPs エントリがその鍵を拠点のプレフィックスに結び付けます。IKEv2の用語では、証明書または事前共有鍵が拠点を識別し、トラフィックセレクタが運べる範囲を定めます。片方だけを変えると取り決めが壊れるため、アドレスの変更を識別情報の変更として扱ってはいけません。

鍵や証明書の所有権はハブ運用者ではなく拠点側に置き、事業者の変更が識別情報の変更にならないようにします。

プレフィックスは計画を忘れられがちな部分です。ハブはセンサーのサブネットを正しいピアに関連付ける必要があり、運用者のクライアントにはそこへの経路が必要で、クライアントにしか存在しない経路は通信を黙って捨てるトンネルへ流し込みます。鍵のフィンガープリントの隣にプレフィックスを拠点の記録へ書き、交換したゲートウェイが気付かれずに別のカバレッジで上がらないようにします。

センサーのアドレスはアプリケーションのもの

拠点の計画にあるプライベートアドレスで十分で、必要なのは公開の到達性ではなく安定性であり、DHCP予約、固定割り当て、拠点自身のゾーン内の名前などで確保します。機器を採番し直せない場合、拠点ゲートウェイでの変換は、変換が文書化され、戻りの通信がそれに従うことを条件に正当な答えです。

もう一つ続けたい習慣は、公開ハブのアドレスを、センサーのホストのネクストホップ欄に貼り付けないことです。VPNは自前の経路を設定しますし、公開の終端に対する通常のEthernet隣接は、もっともらしく見える設定を生む虚構です。

見落とされるのは戻りの半分です。機器は応答をトンネル側へ返す必要があり、運用者のクライアントへの経路でも、要求を変換した同じゲートウェイ経由でもかまいません。既定ゲートウェイが誤っているセンサーは要求を受け取って何もない先へ応答し、転送の注意書きが、到着と応答の経路指定が一つではなく二つの要件である理由を説明しています。

決めてから境界を書く

誰かが接続する前に、アクセス境界を書き留めます。動く経路は事故でいつのまにか一般アクセスになりがちなので、ゲートウェイをIoTセグメントと、運用者が必要とする特定のサービスに限定してください。読み取り専用の監視と設定権限は別の識別情報を持つ別の役割として保ち、契約終了時にアクセスを外す人を名指しします。

承認はネットワーク所有者のものであり、DMZにいることはアクセス方針ではありません。

導入後の試験は地味ですが決定的で、許可されたプレフィックス内の要求が一つ成功し、ゲートウェイのカウンタが増え、プレフィックス外への意図的な試行が一つ失敗することです。