IPv4・IPv6 対応のサブネット計算機

場面

これから社内のアドレス空間を一から決める。拠点が150か所、工場が16か所あり、クラウドの区画も同じ空間に置く。事業部は数年ごとに再編され、拠点の担当地域も入れ替わる。10/8 のどこに何を置くかを最初に決める段階にある。

前提

10/8 を自社で自由に切れること。将来の統合で他社の空間と混ざる可能性を、いまは考えないでよいこと。用途の種類を後から足せること。境界を参照するフィルタの行数を数えられること。

割り当て

理由

10/8 で最初に決めるのは、第2オクテットに何の意味を持たせるかである。候補は3つで、用途で分けるか、組織で分けるか、地理で分けるかになる。

結論から言えば、用途で分ける。組織と地理は変わるが、用途は変わらないからだ。事業部は数年で再編される。担当地域の入れ替えも起きる。それに対して、工場が拠点に変わることはないし、検証環境が本番になることもない。

組織で分けると、再編のたびに境界を動かすか、名前と実態がずれたまま残すかの二択になる。選ばれるのはほぼ必ず後者で、数年後には営業の領域に別の部署がいる状態になる。そうなると、設計書の区分と実機の中身が食い違う。

最上位の境界は動かせない。10.16.0.0/12 は工場、という前提でフィルタが書かれているからで、境界が動けば参照している行を全部見直すことになる。150拠点と16工場とクラウドを抱えていれば数百行になり、しかも一斉に切り替えないと、片方向の通信だけが通る時間が生まれる。

だから最初に決める量を最小にする。10/8 を /12 で分けると、用途に渡せる面は16になる。用途を4つから始め、足りなくなったら面を1つ増やす。面は足すだけで増やせるので、既存の境界は動かない。16面のうち4面しか使わないのは無駄に見えるが、動かさずに済むことのほうが価値がある。

拡張の余地

/12 の面は16ある。全社共通、拠点、工場、クラウドで4面を使い、12面が空く。用途を足すときは 10.64.0.0/12 のように空いている面を1つ渡し、既存の境界は動かさない。検証やIoTのように後から出てくる用途も、既存の面を割らずに新しい面を取る。次にどの面を渡すかは、必要になった時点で決める。

落とし穴

• 第2オクテットを組織で分ける。組織は数年で再編されるのに境界は動かせないので、名前と実態がずれたまま残る。分けるのは用途にする。
• 用途の種類を最初から細かく作る。使われない面が増えるだけでなく、新しい要求がどの用途に当たるかの判断が毎回必要になる。4つ程度から始め、必要になってから足す。
• 足りなくなった用途のために、隣の面の一部を借りる。境界が面の途中に生まれ、以後その面だけ2つの用途が混ざる。足りないなら面を1つ渡す。
• 分け方の結果だけを残し、理由を残さない。次の担当はどの面が何かは読めるが、なぜ用途で分けたかは読めないので、組織で分け直す提案が定期的に出る。
• 全社共通の領域を最後に取る。使いやすい面が先に配られ、全社共通が離れた面に散る。全社共通は最初の面に取る。

場面

100名規模の会社で、現場の装置や検証用の機器を 192.168 系に置いている。取引先や委託先と拠点間をつなぐ話が出るたびに、相手の構内と番号が当たって調整が発生する。在宅勤務の接続でも持ち込みの無線ルータと当たることがある。

前提

相手先の構内で使われている番号を、事前に聞けるとは限らないこと。外と経路をつなぐ機器と、つながない機器を分けられること。装置の番号を後から変えるには立会と再設定が要ること。10/8 も使える状態にあること。

割り当て

理由

192.168.0.0/16 は自社だけのものではない。家庭用の機器、持ち込みの無線ルータ、取引先や委託先の構内が同じ空間を使っている。既定値が 192.168.0 と 192.168.1 に集まることはよく知られているが、問題はそこだけではない。小さな機器の既定値は 192.168.10 や 192.168.100 にも散っていて、相手先が何を使っているかは、たいてい事前に聞けない。

当たった面を避ける方式にすると、避けた記録が増え続ける。10年も運用すれば避けた面は数十になり、新しい相手先が出るたびに一覧との照合が必要になる。照合は人がやるので抜ける。

そこで逆にする。使う範囲を上位ビットで固定し、第3オクテットが128以上の側だけを自社のものとする。半分を捨てることになるが、判断が1回で終わる。100名規模なら使う面は10にも満たないので、128面あれば十分に余る。

置くものも限る。この空間に置いてよいのは、他社や他拠点と経路がつながらないものだけである。衝突が避けられない空間だと分かっているなら、衝突しても困らないものだけを置けばよい。拠点間の接続の先から見えるもの、相互接続に出るものは 10.0.0.0/8 から取る。

拡張の余地

自社が使うのは第3オクテットが128以上の側だけで、128面のうち4面を使う。残る半分の 192.168.0.0/17 は空けたままにし、相手先が増えても面ごとの照合はしない。判断は第3オクテットが128以上かどうかの1回で終わる。外と経路をつなぐものが出てきたら、この空間には置かず 10.0.0.0/8 から取る。装置が増えても使う側の半分で足りる。

落とし穴

• 192.168 の全体を自社の空間として使う前提で切る。相互接続のたびに衝突が出て、そのつど面を避ける対応になり、避けた記録が散らばる。使う範囲を上位ビットで固定する。
• 当たった面の一覧を作って回避する。相手先が増えるたびに照合が要り、人がやるので抜ける。判断が上位ビット1回で終わる形にする。
• 外から見える装置をこの空間に置く。相手の構内と当たったとき、避けられるのは自社側だけなので、装置の番号を変えることになる。外に出るものは 10.0.0.0/8 から取る。
• 半分を捨てるのはもったいないという理由で、使わない側も使い始める。使い始めた面は戻せず、判断の簡単さだけが失われる。100名規模なら128面で余る。

場面

従業員100名前後、1フロアまたは2フロアの本社・支社。有線と無線の両方を使い、ファイルサーバとNASを社内に置いている、もっとも典型的な構成。

前提

L3スイッチまたはVLAN対応ルータが1台以上あること。DHCPは機器側またはサーバ側のどちらでもよい。将来3年で人員が1.5倍になる可能性を見込む。

割り当て

理由

100名規模で最初に迷うのは「/24 一本で足りるか」だが、答えは、有線だけなら足りるが、/24 一本で切ってはいけない、である。有線クライアントだけなら /24 で収まる。しかし社用スマートフォンとノートPCの無線接続を数えると、1人あたりの端末数は実際には2〜3台になり、/24 の254個はすぐ埋まる。

そこで /22 を確保し、内部を /24 と /26 で切る。クライアントと無線をそれぞれ独立した /24 にするのは、DHCPプールの枯渇が片方に波及しないようにするため。サーバと管理を /26 に留めるのは、この規模では60台を超えることがまずなく、大きく取ると第3オクテットの読みやすさが失われるからだ。

第3オクテットに意味を持たせているのも意図的で、0=有線、1=固定IP機器、2=無線、3=第2フェーズ用、と対応させておくと、パケットキャプチャやログを見た瞬間にどのセグメントかが分かる。この可読性は障害対応の速度に直結する。

拡張の余地

10.20.3.0/24 をまるごと空けてあるため、人員が1.5倍になっても無線を /23 に広げるか、部署別セグメントを1つ追加できる。サーバの /26 が窮屈になった場合は、10.20.1.128/27 のプリンタを 10.20.1.192/27 へ移し、空いた 10.20.1.128/26 へ機器管理を移せば、10.20.1.0/25 としてサーバを倍にできる。拠点をもう1つ増やす場合は 10.21.0.0/22、10.22.0.0/22 と続け、10.20.0.0/14 として集約する。

落とし穴

• 192.168.1.0/24 や 192.168.0.0/24 を社内に使ってしまう。家庭用ルータの既定値と衝突するため、在宅勤務のVPN接続で経路が壊れる。10/8 から切り出すのが無難。
• 無線とクライアントを同一セグメントにまとめる。ゲスト用SSIDを後から足したくなったとき、アドレス設計からやり直しになる。最初から分けておくコストはほぼゼロ。
• ネットワーク機器の管理アドレスをクライアントセグメントに混ぜる。ACLで管理面だけを絞れなくなり、監査で必ず指摘される。
• 予備の /24 を「空いているから」と目先の用途に使ってしまう。予備は使わないことに価値があるので、名前を「予備」ではなく「第2フェーズ用」にしておくと守られやすい。

場面

座席を固定しない100席規模の拠点。在籍120名に対し、出社率が日によって40%から80%まで振れる。全員がノートPCを持ち歩き、有線ポートは会議室と一部の固定席にしか残っていない。派遣や常駐委託の短期滞在者が常時10名前後いる。

前提

無線が拠点全体を覆い、社員端末は無線だけで業務が成立すること。DHCPのリース時間をセグメントごとに変えられること。入退室の記録などから、日ごとの在席人数の実績を後から取り出せること。座席予約制度は導入していない前提とする。

割り当て

理由

プールの大きさを決めるとき、最初に出てくる数字は席数の100と在籍の120である。まず席数は外す。次に考えるのはピーク在席の端末数で、出社率80%なら96名、1人がノートPCと社用スマートフォンを持つので192台になる。ここまでなら /24 の254個で入る。

外れるのはこの先だ。フリーアドレスでは今日誰が来るかが決まらない。リース時間を24時間にしていると、昨日来て今日来ない人の端末のアドレスがまだ生きている。出社率が40%と80%で振れるとは、2日続けて来る人の重なりが小さい日があるということだ。40%（48名）の翌日が80%（96名）で顔ぶれがほとんど重ならなければ、2日間に来た人は在籍の120名に近づき、生きているリースは最大で240台になる。/24 の254個の94%で、残りは14個しかない。枯渇はプールが埋まった日ではなく、顔ぶれが入れ替わった日に起きる。数えるべきはピーク在席ではなく、リース時間のあいだに来うる人数、つまり在籍に近い数である。

ではリースを短くすればよいかというと、下限がある。昼休みと午後の会議で端末を閉じると3〜4時間は無通信になり、リースを2時間にすると復帰時に別のアドレスを取る端末が出る。上限はプールの大きさ、下限は働き方が決める。両方を満たすには /23 を取るしかない。510個あれば240台でも53%残る。

/23 を取った時点で第3オクテットとセグメントの対応は崩れるが、この拠点では読みやすさより枯渇の回避を優先する。なお、常時移動しながら通信する端末を同じプールに載せる場合は別の判断が要る。

拡張の余地

隣の 10.16.10.0/23 を空けてあるのは将来のためではなく、プールを1つのサブネットとして広げるためである。プールは分割して足せないので、/23 を /22 にするには隣接する /23 が丸ごと空いている必要がある。判断点を在籍210名に置いたのは、2日間でほぼ全員が来れば420台となり、/23 の510個の82%に達するからである。ここを併合して 10.16.8.0/22 とし、リース時間は据え置く。この制約から、有線もサーバも 10.16.12.0/24 へ押し出されている。解放してよい条件を先に決めておかないと、空きは必ず別の用途に取られる。

落とし穴

• 席数でプールを決める。100席だからと /25 を切ると、1人2台と短期滞在者を数えた時点で足りず、運用を始めた週に枯渇する。数えるのは席ではなく端末である。
• 枯渇を避けるためにリース時間を短くして回転を上げる。昼休みや会議のあとに復帰した端末が別のアドレスを取って通信が切れるが、切れるのが復帰の瞬間だけなので再現せず、報告も上がってこない。
• 短期滞在者の端末を社員と同じプールに入れる。在籍数から見積もった台数と実際がずれ続け、増員のたびに何台不足したのかを説明できなくなる。数が読める側と読めない側は分ける。
• 有線ポートに固定IPを配る運用を残す。フリーアドレスでは同じポートに毎日違う人が座るため、番号と利用者の対応がすぐ崩れ、台帳だけが残る。有線もDHCPで配る。

場面

本社1、地域ハブ8、営業所と倉庫が141の合計150拠点。各拠点は地域ハブ経由で本社につながり、経路は地域ハブでまとめて上位へ流す。拠点番号は資産管理と帳票で既に使われており、開設順に振られている。年に数か所が開き、数か所が閉じる。

前提

地域ハブが配下の拠点を1本にまとめて広告できること。拠点番号の体系が既にあり、アドレス設計の都合では振り直せないこと。1拠点の端末が1000台を超えないこと。拠点がどの地域に属するかが、年単位では変わらないこと。

割り当て

理由

150拠点を上位へ150本の経路で流さないために集約する。だが集約に要るのはアドレスのブロックが連続していることで、拠点番号が連続していることではない。ここを取り違えると設計が丸ごと無駄になる。

拠点番号は既にある。資産管理と帳票で使われ、開設順に振られていて、地域とは対応しない。この番号をそのまま第2オクテットに写すと、地域3のハブが抱えるのは拠点3、17、42、88という飛び飛びの集合になる。飛び飛びのブロックは1本にまとまらないので、上位へ出る経路は150本のまま残る。集約のために番号を振り直すことはできない。番号は帳票と呼称に埋まっている。

だから順序を逆にする。集約の単位、つまり地域ハブを先にブロックへ割り当て、拠点番号はそのブロックの内側で識別子として配る。地域8つに第2オクテットを1つずつ、拠点には /22 を1つずつ。1地域は64拠点まで入る。150拠点は最大でも1地域24拠点で収まり、上位へ流れる経路は8本になる。拠点が倍の300に増えても8本のままである。

代償は、アドレスから拠点番号が読めなくなることだ。読めるようにすると地域の連続性を捨てることになる。障害対応で必要なのは番号の規則ではなく、拠点番号とブロックの対応表1枚である。

拡張の余地

地域の枠は第2オクテットの1から8で、0は全社共通に使う。9から15の7面は空けておき、地域の増設と、64拠点を超えた地域に渡す2面目の地域枠に充てる。番号は連続しないので対応表で引く。10.16.0.0/12 より上は手をつけず、買収や別事業の受け入れに残す。

落とし穴

• 拠点番号をそのままアドレスに対応させる。番号は開設順で決まり地域とは対応しないため、同じハブの配下が飛び飛びになり、上位へ出る経路が拠点数のまま残る。番号は地域の枠の内側で配る。
• 拠点間リンクのアドレスを、その拠点のブロックから取る。相手が別の地域の拠点だと、この地域の枠のアドレスが別の地域に置かれ、その分だけ細かい経路が上位に出る。リンクは拠点ブロックの外の共通枠から取る。
• 拠点内のセグメントを、拠点の枠の境界をまたいで足す。はみ出した分は集約に含まれず、その拠点だけ細かい経路が上位に出る。足すのは枠の内側に限り、超えたら2枠目を渡す。
• アドレスから拠点番号が読めることを要件にする。読めるようにすると地域の連続性を捨てることになり、集約が成立しなくなる。必要なのは番号の規則ではなく対応表である。
• 1拠点だけを、地理の都合で別の地域ハブに収容する。アドレスは元の地域の枠のままなので、上位には地域の枠とその拠点だけの経路が並ぶ。収容を替えるならアドレスごと移す。

場面

点対点リンクを300本以上持つ網で、リンクのプレフィックス長を決める。機器は世代が混ざっていて、古い装置と特定用途の装置、仮想の機器が同居している。アドレスを節約したいという理由で /31 への統一が提案されている。

前提

リンクの両端にある機器の型と世代を一覧にできること。機器が /31 を扱えるかを事前に確認できること。払い出しを1か所で行っていること。リンクのアドレスを後から変えるには設定と監視の書き換えが要ること。

割り当て

理由

/30 は4つのアドレスのうち2つしか使えず、/31 は2つとも使える。必要なアドレスの数は半分になる。

だが節約としては意味がない。リンクが352本なら、/30 で1408アドレス、/31 で704アドレス。差の704は、リンク用に取った /16 の面のおよそ1パーセントにすぎない。この差のために判断を変える理由はない。

決め手は機器がそろうかどうかである。/31 はすべての機器が扱えるわけではない。古い装置、特定用途の装置、仮想の機器のどれかが対応していないことがある。リンクは両端に機器が1台ずつあるので、1台でも非対応なら、そのリンクは /30 になる。

混在させると払い出しの手順が変わる。プールの中に2つの単位が混ざり、払い出しのたびに両端2台の対応を調べることになる。月に10本なら年120回である。節約した704アドレスに、年120回の調査の価値はない。

だから統一する。全機器が対応しているなら /31、1台でも非対応が残るなら /30 である。どうしても混ぜるなら帯を分け、払い出しのたびに調べずに済むようにする。

もう1つ。一度 /30 で切ったリンクは、機器が入れ替わっても /31 には移らない。移すにはアドレスを変えることになり、設定と監視の名前が書き換わるからである。いずれ移すという前提は置かない。

拡張の余地

既定は /30 で、対応を確認できた区間だけを /31 の帯から切る。帯を分けるのは、払い出しのときに機器の対応を調べずに済ませるためである。/31 の帯に区間を足すのは、両端の機器が入れ替わって対応を確認できたときだけにする。増分は 10.161.16.0/21 から出す。全機器が入れ替わっても、既にある /30 のリンクは切り替えない。新しく作る分だけを /31 にする。

落とし穴

• アドレスの節約を理由に /31 を選ぶ。節約できるのはリンク用の面のおよそ1パーセントで、判断を変える理由にならない。決め手は機器がそろうかどうかである。
• 2つの単位を同じ帯に混ぜる。払い出しのたびに両端2台の対応を調べることになり、月10本なら年120回の作業が増える。混ぜるなら帯を分ける。
• 非対応の機器が1台あるのに /31 を既定にし、その区間だけを /30 の例外にする。機器を入れ替えるたびに対応の確認が要り、1回でも忘れるとそのリンクが使えなくなる。既定は /30 にし、/31 は対応を確認した区間の帯から切る。
• いずれ /31 へ移すという前提で /30 を選ぶ。移すにはアドレスを変えることになり、設定と監視の名前が書き換わる。移らない前提で決める。

場面

100名規模の会社で来客用の無線を用意する。平常時の来客は20台ほどだが、説明会や展示の日には400台が一度に来る。社内への通信はフィルタで止めているが、名前解決とアドレスの配布は社内と同じ機器を使っている。

前提

来客用の無線を社内の無線と別の帯として出せること。来客用の出口を外向きに1本用意できること。名前解決と配布の機器を来客用に別に置けること。172.16/12 の中に使える位置があること。

割り当て

理由

来客無線に求められるのは、社内から見えないことだと思われている。フィルタで社内への通信を止めれば済む、という考え方である。これでは足りない。

来客の帯が社内と共有しているものは、フィルタの外にもある。名前解決を社内の機器で引かせれば、来客の端末は社内のサーバ名を問い合わせられる。答えを返さなくても、どの名前が存在するかは問い合わせの反応から分かる。アドレスの配布を社内と同じ機器で行えば、100名の会社に400台が来るイベントの日に、社内の配布まで詰まる。時刻を社内に合わせさせれば、社内の時刻サーバへの経路を1本開けることになる。

だから来客の帯は、社内と何も共有しない。社内のどのセグメントへも経路を持たせず、出口は外向きの1本だけにする。名前解決も配布も、来客のためだけに別に持つ。フィルタで塞ぐのではなく、塞ぐべき経路がそもそも存在しない形にする。塞いだ経路は1行で開くが、ない経路は開けようがない。

番号の選び方にも理由がある。来客の端末の多くは、自分の会社へ接続を張る。相手の社内が 10/8 を使っていれば、来客の帯が 10/8 にあると相手側で番号が当たり、来客は自社につながらなくなる。帯は 172.16/12 の中の、あまり使われない位置から取る。

拡張の余地

来客の帯は社内のどこにも経路を持たず、出口は外向きの1本だけにする。名前解決と配布も来客用に別に持つ。イベントで端末が増えたら 172.30.4.0/22 を足して受け、足した分も同じ出口から出す。社内への経路は増やさない。帯は 172.16/12 の中に取り、来客の会社が使っていそうな 10/8 とは重ねない。

落とし穴

• 社内への通信をフィルタで止めて済ませる。名前解決や配布を社内と共有していれば、フィルタの外で社内の情報が漏れ、負荷も伝わる。何も共有しない。
• 来客の端末に社内の名前解決を使わせる。答えを返さなくても、どの名前が存在するかが問い合わせの反応から分かる。来客用に別に持つ。
• 来客の配布を社内と同じ機器で行う。イベントの日に来客が急増すると、社内の配布まで詰まる。配布は来客用に分ける。
• 来客の帯を 10/8 から取る。来客が自分の会社へ接続を張ったとき、相手の社内と番号が当たってつながらなくなる。172.16/12 のあまり使われない位置から取る。

場面

500名規模の会社で、DMZ に置く機器が年々増えてきた。公開用のWebサーバ、取引先とファイルを受け渡すサーバ、外からのメールを受ける機器、外のサービスを呼び出すだけのサーバ、監視の通知を外へ送る機器が、1つの帯に同居している。

前提

外から始まる通信を受ける機器と、外へ出ていくだけの機器を区別できること。取引先との接続の相手が特定できること。DMZ の帯を相手ごとに分けて出せること。帯の間の通信を境界で止められること。

割り当て

理由

DMZ に何を置くかの基準は1つである。外から始まる通信を受ける機器を置く。

基準がないと、外と話すものが全部入っていく。社内から外へ出ていくだけの機器、外のサービスを呼び出すだけのサーバ、監視の通知を外へ送る機器。これらは外から始まる通信を受けないので、DMZ に置く理由がない。置くと DMZ が膨らみ、どれか1台が侵入されたとき、隣にいる全部に届くようになる。

置くものを決めたら、次に受ける相手で分ける。公開用と取引先用は同じ帯に置かない。公開用は誰でも来るので、侵入される前提で考える。取引先用は相手が決まっているので、許可はずっと狭い。同じ帯にあると、公開用のサーバが侵入されたとき、取引先と受け渡すファイルに隣から届く。相手を絞った意味がなくなる。

分けた帯の間の通信は許可しない。公開用から取引先用へ行く理由は、業務の上で1つもないからである。

新しく外から受ける機器が出てきて、誰から受けるかがはっきりしないときは、公開用に入れる。相手を絞れない機器を取引先用に入れると、取引先用の帯の前提が崩れる。

拡張の余地

DMZ は受ける相手ごとに分け、公開用と取引先用は別の帯に置く。帯の間の通信は許可しない。新しく外から受ける機器が出たら、誰から受けるかで帯を決め、決まらなければ公開用に入れる。帯が足りなくなったら 10.170.1.0/24 から切る。外へ出ていくだけの機器は、増えても DMZ には入れない。

落とし穴

• 外と通信するものを全部 DMZ に入れる。外へ出ていくだけの機器まで入ると DMZ が膨らみ、1台の侵入が隣の全部に届く。置くのは外から始まる通信を受ける機器だけにする。
• 公開用と取引先用を同じ帯に置く。公開用が侵入されたとき、取引先と受け渡すファイルに隣から届く。受ける相手ごとに帯を分ける。
• 分けた帯の間の通信を、念のためと言って許可しておく。業務上の理由がない許可は、侵入されたときの通り道にしかならない。帯の間は許可しない。
• 相手がはっきりしない機器を取引先用に入れる。取引先用の帯は相手が決まっているという前提で許可を狭めているので、その前提が崩れる。迷ったら公開用に入れる。

場面

クラウドの区画に、機器10台を置く小さなサブネットを障害区域ごとに作る。社内の網と同じ感覚で /28 を切れば14台置けるはずだと考えている。同じ区画には200台ほどのアプリケーションのサブネットも並ぶ予定である。

前提

使う事業者が、サブネットの中の番号をいくつか先に取ることを知っていること。事業者が取る数と、作れる最小の大きさを確かめられること。サブネットを作ったあとで大きさを変えられないこと。区画の中に空きがあること。

割り当て

理由

クラウドでサブネットを作ると、事業者がその中の番号をいくつか先に取る。事業者によって違うが、先頭の4つと末尾の1つ、合わせて5つを取る形が多い。社内の網では使えないのは先頭と末尾の2つだけなので、この差を知らないまま切ると足りなくなる。

差は小さいサブネットほど効く。/24 なら256のうち5で、2パーセントにすぎない。/26 なら64のうち5で8パーセント。作れる最小の /28 では16のうち5で、約3割が消える。使えるのは11である。

社内の感覚で /28 を切ると、14台置けるつもりで11台しか置けない。10台の機器を置くなら余裕は1台しかなく、2台足した日に溢れる。サブネットは作ったあとで大きさを変えられないので、溢れたら作り直しになる。

だから小さいサブネットを切るときは、予約を引いた数で台数と比べる。10台なら /28 ではなく /27 を取る。/27 なら32のうち5を引いて27が使える。小さく切るほど損の割合が大きいので、小さいサブネットは社内より一段大きく切るのを基本にする。

予約の数は事業者で違い、作れる最小の大きさも違う。計算タブで予約の型を選べば、使える数がその場で出る。見積もりはそこで確かめる。

拡張の余地

小さいサブネットは、予約の5つを引いてから台数と比べる。10台なら /28 ではなく /27 を取る。障害区域ごとに同じ大きさで並べ、区域の数だけ作る。サブネットが増えたら 10.216.2.0/24 から切る。見積もりに迷ったら、計算タブで予約の型を選んで使える数を確かめる。

落とし穴

• 社内の感覚で使える数を数える。先頭と末尾の2つだけを引くと、事業者が取る残りの3つを見落とし、置けるつもりの台数が入らない。予約を引いた数で比べる。
• 作れる最小の /28 を標準にする。16のうち5が消え、使えるのは11しかない。数台足しただけで溢れる。10台規模なら /27 を取る。
• サブネットは後から広げればよいと考える。作ったあとで大きさは変えられず、溢れたら作り直しになる。最初に予約込みで見積もる。
• 予約の数をどの事業者も同じだと考える。事業者によって取る数も、作れる最小の大きさも違う。使う事業者の型で確かめる。

場面

買収した会社の網を自社の網とつなぐ。どちらも 10/8 を使っていて、いくつもの帯が重なっている。業務の都合で来月にはつながっていなければならず、どちらかを振り直す時間はない。境界で番号を変換してつなぐ案が出ている。

前提

両社の網の間に、番号を変換できる境界を1か所置けること。変換後の番号を、どちらの空間にもない場所から取れること。変換の規則に期限を書き込めること。振り直す側を経営の判断を待たずに決められること。

割り当て

理由

重複した2つの網をつなぐ方法は2つある。どちらかを振り直すか、境界で番号を変換するかである。変換は一晩で入り、振り直しは数か月かかる。統合の初期に変換を選ぶのは正しい。

問題は、変換が恒久化することにある。変換で通信が通ってしまうので、振り直す理由が消える。3年後には変換の規則が積み上がり、誰も全体を説明できなくなる。障害のたびに、ログに出た番号が変換の前か後かを確かめることになる。

だから変換を入れる日に、2つを同時に決める。期限と、振り直す側である。期限は日付で決め、変換の規則そのものに書いておく。振り直す側はその日のうちに決め、変換の期間は振り直しの準備期間として扱う。どちらを振り直すかが決まっていない変換は、期限が来ても延ばすしかない。

変換後の番号は、どちらの空間にもない場所から取る。自社も相手も 10/8 を使っていて重なったのなら、変換後の番号は 172.16/12 から取る。どちらかの 10/8 の空きを使うと、次に別の会社を受け入れたときにまた重なる。

恒久でよい変換もある。同じ構成を複製したラインのように、同じ番号が並び続けることが設計の前提なら、変換は恒久で正しい。統合での重複は前提ではなく事故であり、事故の手当てを恒久にしてはいけない。

拡張の余地

変換後の帯は 172.16/12 の中に取り、相手の網を見る帯と、自社の網を相手に見せる帯を分ける。変換の規則には期限を書き、期限までに、変換を入れた日に決めた側を振り直す。期限までに増える分は 172.18.24.0/22 から切る。期限を過ぎた変換は延長せず、延長が要るなら振り直す側の判断からやり直す。

落とし穴

• 変換を入れるときに期限を決めない。通信が通ってしまうので振り直す理由が消え、変換の規則が積み上がって誰も説明できなくなる。
• 振り直す側を決めずに変換を入れる。期限が来ても、どちらを動かすかの議論から始まるので延ばすしかない。変換と同じ日に決める。
• 変換後の番号を自社の 10/8 の空きから取る。次に別の会社を受け入れたときに、また重なる。どちらの空間にもない場所から取る。
• 変換を1台ずつの規則で書く。期限の管理も1台ずつになり、どれが残っているか分からなくなる。帯の単位で書く。

場面

同じ装置構成の製造ラインが複数あり、今後もラインを増やす予定の工場。装置ベンダから納入された制御機器に固定IPが焼き込まれており、ライン間で同じアドレスが重複している状態から始める。

前提

各ラインの制御機器のアドレスが変更不可、または変更に装置ベンダの再検収が必要であること。ライン間の直接通信は不要で、上位の収集系とだけ通信すればよいこと。ライン境界にL3機器またはNAT可能な機器を置けること。

割り当て

理由

OTネットワークがITと決定的に違うのは、アドレスを自由に決められないことである。装置ベンダは複数の顧客に同じ構成を納入するため、制御機器のアドレスは出荷時に固定されており、ライン2にもライン3にも同じ 192.168.0.10 が存在する。これをIT側の常識で「重複しているから振り直す」とやると、装置の保証と再検収の話になり、現場は止まる。

そこで振り直さない。ライン内部のアドレスは装置ベンダの設定のまま触らず、ライン境界の機器で 1:1 のアドレス変換をかけ、外から見えるアドレスだけをライン番号で分ける。ライン1の制御機器は外からは 172.20.1.x に、ライン2の同じ機器は 172.20.2.x に見える。第3オクテット＝ライン番号という規則にしておくと、収集系のログを見た人が機器名を知らなくてもどのラインかを即座に判別できる。

この設計の本質は、装置ベンダの都合とIT側の管理性を、変換という一枚の層で分離することにある。ライン内部は「装置ベンダの世界」、境界から上は「情シスの世界」と割り切る。ライン増設のたびに設計をやり直さず、番号を1つ増やして同じ設定をコピーするだけで済むのが最大の利点である。

拡張の余地

直近の増設用に 172.20.4.0/22（ライン4〜7）を予約してある。基準ブロックが /16 なので、第3オクテットをライン番号に使う規則のままライン255まで届き（0 はライン番号に使わず、収集・保守の共通に充てる）、8以降は 172.20.8.0/21、172.20.16.0/20 と自然に続けられる。工場が増える場合は第2オクテットを工場番号として 172.21.0.0/16 を次の工場に割り当て、172.20.0.0/15 で集約する。1ラインが /24 で足りなくなるのはライン内の制御機器が250台を超える場合だが、その規模ではラインを論理的に分割する方が運用しやすい。

落とし穴

• ライン間の通信を「念のため」許可してしまう。1ラインがマルウェアに感染したとき、同一構成の全ラインが同時に止まる。ライン間は原則遮断し、必要な通信は収集系を経由させる。
• 保守端末のセグメントを用意せず、持ち込みPCを制御セグメントに直挿しする。OTインシデントの入口として最も多い経路で、しかも記録が残らない。専用セグメントを作り、そこからだけ制御側に入れる。
• アドレス変換の対応表を機器の設定内にしか持たない。設定した担当者が異動すると、どの外部アドレスがどの装置かを誰も説明できなくなる。対応表は設計書側の一次情報として持つ。
• 工場のアドレスに 192.168 系を使う。保守ベンダが持ち込むルータやモバイルルータと衝突しやすく、しかも衝突は現地でしか発覚しない。172.16/12 か 10/8 から切る。
• ライン番号とアドレスの対応を、増設のたびに空いている番号を埋める形で決める。ライン7が撤去されて後に別の装置が入ると、番号と現物がずれて誰も信用しなくなる。番号は再利用しない。

場面

敷地内に事務所棟と工場棟があり、これまで1つのネットワークとして運用してきた従業員300名規模の工場。生産管理システムから装置への指示と、装置からの実績収集は今後も必要だが、事務所のPCから制御機器へ直接到達できる状態は解消したい。ライン内部の設計には手を入れず、上下の境界だけを先に引き直す段階。

前提

事務所側と工場側の間にL3機器を1台以上置けること。両側をまたぐ通信を、少なくとも受け渡しサーバ単位で相手と向きごとに洗い出せること。制御機器のアドレスは今回変更せず、ライン内部の再設計は別に行う。境界機器が停止している間も生産が継続できることを要件に含める。

割り当て

理由

分離することに反対する人はいない。決まらないのは、境界に置く区画をどのサイズにするかである。

境界を /24 で取ると必ず失敗する。この規模で本当に両側と通信する必要があるのは受け渡しのサーバだけで、十数台に収まる。残る240個以上は空き地になり、空き地は必ず埋まる。半年後には情報系のファイルサーバが、翌年には事務所側の認証基盤に参加した踏み台が入る。その時点で境界は境界でなくなるが、アドレス表の上では何も変わらないので誰も気づかない。

だから受け渡しは /28 に留める。14個しかなければ、15台目を置こうとした人が必ず誰かに相談する。サイズを運用ルールとして働かせるのが狙いで、増設余地は隣に別名の第2フェーズ用として置き、受け渡し区画そのものは広げない。

/20 を 0〜3（IT）・4〜7（境界）・8〜15（制御）の3領域に割ったのも意図的である。境界機器のフィルタが 10.60.0.0/22、10.60.4.0/22、10.60.8.0/21 の3行で書き切れ、セグメントを足してもこの3行は変わらない。追加のたびにフィルタを触る設計は、いつか触り間違えて生産を止める。

制御系共通の区画（/25）を制御側に置いたのは可用性のためだ。境界機器が落ちている間も生産は続く。時刻同期と名前解決を事務所側に依存させると、境界の停止がそのまま制御側の停止になる。

拡張の余地

境界は 10.60.4.64/26 を第2フェーズ用として空けてある。受け渡しの拡張ではなく、外部データ連携やリモート保守の中継を後から足す場所である。制御側はライン別区画として 10.60.12.0/22 を空けてあり、ライン単位の設計はここに載せる。無線が /24 で足りなくなったら 10.60.10.0/23 を追加する。工場が増える場合は 10.60.16.0/20 を次の工場に割り当て、10.60.0.0/16 で集約する。3領域の境目を /22 に揃えてあるため、どの工場でもフィルタの3行が同じ形になる。

落とし穴

• 境界に踏み台サーバを置き、それを事務所側の認証基盤に参加させる。認証情報が事務所側から流れ込む経路ができ、境界の意味が消える。踏み台を置くなら認証は境界の中で閉じる。
• 制御機器の時刻同期先を事務所側のサーバのままにする。境界機器を止めた瞬間に制御側の時刻がずれ始め、後から障害を追うときにログを突き合わせられない。時刻同期は制御側に置く。
• 分離の要件を「事務所から制御系へ入れないこと」だけで定義する。制御側から事務所側への通信が野放しになり、装置に紛れ込んだ端末が外へ出る経路が残る。向きは両方向で決める。
• 受け渡しサーバに収集もファイル置き場も兼務させる。止められない側の都合で更新できなくなり、数年で誰も触れないサーバになる。役割ごとに分け、/28 の中で台数を管理する。

場面

拠点が10か所ある会社で、回線の事業者から IPv6 の /48 を受け取った。これまで IPv4 では、台数に合わせてサブネットの大きさを変え、予備の位置や細切れに気を配ってきた。同じ考え方で IPv6 の割り当てを始めようとしている。

前提

事業者から /48 を受け取っていること。社内の機器が IPv6 の自動の番号決めを使えること。拠点と用途の数がそれぞれ15以下に収まる見込みであること。番号を人が読んで意味を取る運用であること。