VPN経由でPLC検出が失敗する？ Ethernetを機械のそばに残す
保守ツールに必要なのはルートであり、ブリッジされたEthernetセグメントではありません。セグメントに管理対象ホストを置き、LANを延伸するのではなくそのホストを制御します。
検出ボタンはいつまでも回り続け、何も見つからず、チケットには機械がオフラインだと書かれています。機械は正常です。ツールがそのセグメントで機器を見つけるために使うものは、与えられた経路を越えられず、そこで反射的に、ボタンが再び動くように顧客のEthernetを拠点間リンク越しに延伸しようとします。まず依存関係を洗い出してください。ほとんどの保守ツールはルートを必要としますが、本当にケーブルが必要な場合は、二つの建物の間にブリッジされたネットワークではなく、機械のそばに置いた管理対象ホストが持続的な答えです。
ルーティングされたトンネルの端で検出が死ぬ理由
ルーティングされたトンネルはサブネット間でユニキャストパケットを運びます。ブロードキャストとマルチキャストのフレームは一つのブロードキャストドメイン内にとどまり、VPNの端点はまさにそのドメインが終わる場所です。セグメントに叫んで機器を見つけるツールは、叫びが転送されることはなかったため沈黙を受け取ります。
同じことは、まったくIPではないプロトコルや、Ethernet上を直接走るベンダーのフレームにも当てはまります。これらはいかなる設定でもルーティングできず、だからこそ検出の問題にルートやファイアウォールの規則を加えても何も変わらないことがよくあります。
その状態でまだ何が動くかに注目してください。既知のアドレスへのpingや既知のポートへのユニキャスト接続は、トンネルがまさにその部分のために作られたため、たいてい成功します。アドレスでは到達できるのに検出からは見えないというこの組み合わせは、壊れたネットワークではなく、欠けているブロードキャストドメインの証拠です。
トランスポートを選ぶ前に依存関係を名指しする
ツールが機器をどう見つけ、どう話すかをドキュメントで読み、それをこの表と突き合わせてください。
| What the tool needs | Routed tunnel enough | Local segment needed |
|---|---|---|
| Unicast to a known address, such as a web interface or Modbus TCP on 502 | Yes | No |
| Broadcast or multicast discovery of unknown devices | No | Yes |
| Non-IP or vendor-specific Layer 2 frames | No | Yes |
| A tool bound to one adapter or licence keyed to a MAC address | Usually no | Usually yes |
すべての要件が最初の行に当てはまるなら、ここで止まってルーティングを直してください。それはどのトポロジ作業よりも安価で、はるかに見直しやすい変更であり、保守セッションを顧客がすでに承認したアクセス経路の内側に保ちます。
マルチキャスト検出は厄介な中間にあります。リフレクタやリピータはその一部をサブネット越しに転送でき、ボタンが動くようになり、遠隔側が到達できる範囲が静かに広がります。これは所有者のいる意図的な設計として扱うべきで、便利なチェックボックスではありません。
セグメントに管理対象ホストを置き、そこへリモート接続する
監査に耐えるパターンは地味です。顧客が承認したエンジニアリングワークステーションを機械の保守セグメントに接続し、技術者は承認済みのリモートアクセス経路でそのワークステーションに接続します。ツールはケーブルのある場所で動き、人は自分のいる場所から動きます。
そうすれば技術者の家庭ネットワークの何もが機械のEthernetの一部にならず、障害ドメインの共有に同意したことのない二つの拠点の間にブリッジが作られることもありません。
ローカルドメインは作業が許す限り小さく保ちます。管理対象ホストを一台置いた一つの保守VLANには、限られたブロードキャスト範囲、限られたループドメインがあり、障害は午前三時にWANリンク越しに広がるのではなく工場内にとどまります。
そのホストに一つの仕事、一人の所有者、一本の監査証跡を与える
所有者を決め、許可するソフトウェアを列挙し、パッチの当て方を定義し、どの利用者が到達できるかを記録し、作業ファイルと資格情報は正しい顧客に結び付けておいてください。六つの拠点を訪れた共用のエンジニアリング用ノートPCは、発見されるのを待つデータ境界の問題です。
次に、人が忘れる経路を見てください。クリップボード同期、ファイル転送、マップされたドライブ、アダプタ共有はどれも境界を越えてデータを動かし、リモート表示セッションはそのどれも無料では行いません。クライアントの既定を引き継ぐのではなく、この作業のためにそれぞれを明示的に決めてください。顧客の変更ウィンドウも、到達できることは行動の許可と同じではないから、その判断に含まれます。
方針の枠組みについては、NISTのSP 800-82r3は遠隔保守を運用システムへの管理されたアクセスとして扱い、そこでは接続性と設備への影響が一緒に検討されます。
L2延伸をそれ自体の設計として見直す
それでもEthernetを延伸したいなら、独自のリスクを持つ別プロジェクトとして見直してください。統合されたブロードキャストとスパニングツリーのドメインがどう見えるか、二つの組織間でアドレス指定がどう管理されるか、片側でループしたら何が起きるか、各端で誰が変更を承認するかを問うてください。成功したラボ試験はこれらの問いに一つも答えず、機器の互換性、スループット、リンク障害後の復旧を検証することも決してありません。
ローカルホストのパターンを受け入れるには、ツールが存在目的の操作を実行すること、遠隔利用者がこの作業について権限を持つこと、拒否されたシステムがそのホストから到達できないままであることを証明します。その後、作業の合意された終了時に一時アクセスを取り消し、それが消えたことを確認します。
こうして顧客にはローカル保守を行う管理された場所が残り、これは統合されたネットワークより小さな約束であり、守るのははるかに容易です。