LTE VPN リンク上の EoIP: 小さな RouterOS ラボを作る

EoIP は Ethernet フレームを丸ごと受け取り、GRE で包んで設定済みの遠隔アドレスへ送る。だから結果はルートではなくケーブルのように振る舞う。ルーターから出るのは IP プロトコル 47 で、元のフレームがペイロードになるため、ブロードキャストも ARP も IP 以外のプロトコルもすべて通過する。GRE 自体は機密性を何も加えず、外側のパケットを見られるものにとってフレームは読めるままである。この一つの事実がこの実験の順序を決める。まず暗号化された経路を作り、その中で Ethernet を運ぶ。

EoIP が包むもの、包まないもの

カプセル化が仕組みのすべてである。フレームはブリッジされたポートに届き、GRE ヘッダーと外側の IP ヘッダーを受け取り、対向ルーターに渡される。対向ルーターは両方を外して自分のブリッジにフレームを注入する。受け取るブリッジは送信元 MAC をローカルポートから学ぶのとまったく同じように学ぶ。その過程でフレームを認証するものも隠すものもない。

したがって機密性は GRE パケットが通る経路から来なければならない。この設計では下位層は二台のルーター間の WireGuard または IPsec トンネルで、EoIP はその中を運ばれる。MikroTik は EoIP インターフェース自体にも自動 IPsec オプションを用意しているが、それは別の構成であり、この実験で設定するものではない。

ルーティングされた IP サービスには ルーティングされた VPN のほうが小さな設計で、優先すべきものである。レイヤー二に手を伸ばすのは、機器が本当に別拠点の Ethernet フレームを見る必要があるときだけにしよう。

前提条件: 暗号化された下位層と未使用のポート二つ

どちらのルーターにも、確立済みの暗号化リンクと、相手が到達できるその上のアドレスが必要である。外側の接続は LTE 側が開始するので、ハブがモバイル網を発信することはなく、LTE ルーターが事業者の求める NAT 状態を維持する。その上に何かを足す前にトンネルが上がっていることを確認しよう。遠隔アドレスに届かない EoIP インターフェースは、設定ミスのものとまったく同じに見えるからだ。

各ルーターには、すでにブリッジのメンバーでも VLAN トランクでも管理インターフェースでも本番リンクでもないポートが一つ必要である。稼働中のポートを借りる実験は実験ではなく、その故障モードは実運用ネットワークでのブロードキャストストームである。始める前に管理を別のインターフェースかコンソールへ移しておこう。

Hub tunnel address:    10.44.7.1/32
LTE tunnel address:    10.44.7.2/32
Lab ports:             ether7 on both routers, unused
Test hosts:            192.168.77.11/24 and 192.168.77.12/24

これらの値は例であって要件ではない。トンネルのインターフェース上に置き、保護された経路でルーティングする必要がある。両方のルーターのファイアウォールポリシーは二つのトンネルアドレス間の GRE を許可しなければならず、GRE は IP プロトコル 47 であって、47 番の TCP や UDP ポートではない。この設計は生の GRE をどちらの WAN にも決して露出させない。

一致する ID でトンネルのペアを作る

両端は二回定義される一つの論理インターフェースなので、識別フィールドはすべて一致しなければならない。ハブ側では:

/interface eoip add name=eoip-lab local-address=10.44.7.1 remote-address=10.44.7.2 tunnel-id=37 mac-address=02:1A:2B:00:00:01

LTE ルーター側ではアドレスが逆になり、MAC が異なる:

/interface eoip add name=eoip-lab local-address=10.44.7.2 remote-address=10.44.7.1 tunnel-id=37 mac-address=02:1A:2B:00:00:02

トンネル ID は両端で一致しなければならず、どちらかのルーターにすでに設定された別のペアと衝突してはならない。MAC アドレスはローカル管理の値で、参加するレイヤー二ドメイン内で一意でなければならない。だからベンダーの例の値を再利用してはいけない。インターフェース名は各ルーターにローカルで、自分のスクリプトに対して一貫していればよい。

現在の EoIP マニュアル はエンドポイントとトンネル ID のフィールドを記述し、EoIP が GRE 上の Ethernet であると明確に述べている。そのコマンドは何も暗号化しない。だから下位層の確認が先なのである。

テストポートだけをブリッジする

ブリッジがトンネルをセグメントに変えるものであり、その構成が安全境界のすべてである。ハブ側では:

/interface bridge add name=br-eoiphub protocol-mode=rstp auto-mac=no admin-mac=02:1A:2B:00:01:01
/interface bridge port add bridge=br-eoiphub interface=ether7
/interface bridge port add bridge=br-eoiphub interface=eoip-lab

LTE ルーター側では:

/interface bridge add name=br-eoiplte protocol-mode=rstp auto-mac=no admin-mac=02:1A:2B:00:01:02
/interface bridge port add bridge=br-eoiplte interface=ether7
/interface bridge port add bridge=br-eoiplte interface=eoip-lab

これらのコマンドは新しいブリッジを作り、それぞれにちょうど二つのポートを追加する。EoIP インターフェースがレイヤー二のメンバーであり、暗号化されたトンネルはルーティングされたトランスポートのままで、ブリッジポートとして加えてはならない。本番ポートを加えず、実験用ブリッジで DHCP サーバーを起動しないこと。

二台のテストホストには、競合する DHCP サーバーのない未使用サブネットのアドレスを与える。たとえば 192.168.77.11/24 と 192.168.77.12/24 である。そのサブネット内で互いに到達するのにデフォルトゲートウェイは不要で、フレームが通過するのにルーターのインターフェースアドレスも要らない。

LAN を拡張する前にオーバーヘッドを見積もる

IPv4 上の EoIP は、運ばれるペイロードの周りに Ethernet、GRE、外側 IP のヘッダーを加える。タグなしの場合について MikroTik は 42 バイトと記しており、利用可能な IP MTU が 1400 バイトの下位層では内側のフレームに 1358 バイトが残る。この数字は予算であって万能な MSS 値ではなく、ブリッジされたホストに小さいフレームを出させるものでもない。

経路上の実際の限界を確認し、そのうえで機器が実際に送る最大のフレームで試す。保護された経路の内側で分割が必要な 1500 バイトのフレームは、収まるフレームとは振る舞いが異なり、その差はリンク障害ではなくアプリケーションの停止として現れる。

/interface eoip print detail where name=eoip-lab
/interface bridge host print where bridge=br-eoiphub
/ping 192.168.77.12 count=4 interface=br-eoiphub

RSTP が扱うのはループであり、任意の並列経路ではない。だからパイロット構成は単純に保とう。ブリッジを広げることはブロードキャスト、マルチキャスト、DHCP の挙動をモバイルリンク越しに広げることであり、そのトラフィックは有用なフレームが流れていなくても帯域を消費する。

本番接続は、実験が本当に必要なフレームサイズとアプリケーションの挙動に達してから計画しよう。その切り替えの前に、アドレッシング、VLAN の所属、DHCP の権限、ループ防止、そしてリンク自体が落ちているときにどうルーターへ到達するかを合意しておく。Ethernet の拡張は機器だけでなく障害ドメインもつなぐのだから、稼働中のブリッジにもう一つポートを足すのではなく、変更ウィンドウを用意する価値がある。