Remote Access
MikroTik IPsec 拠点間VPN設定ガイド
MikroTikのIPsec拠点間VPNを構築する方法。IKEv2ピア、プロポーザル、ポリシー、そしてトンネルを機能させるNATバイパスルールを設定します。
概要 MikroTikのIPsec拠点間VPNは、2つのネットワーク全体（本社と支店、NOCと基地局サイトなど）の間の通信を暗号化し、それぞれのLAN上のホストが相手側のホストへローカルであるかのように到達できるようにします。本ガイドでは、RouterOS v7上の両方のルーターを設定します。IKEv2ピア、事前共有鍵によるアイデンティティ、フェーズ2プロポーザル、トンネルポリシー、最初の設定でほとんどの人がつまずくNATバイパスルール、そしてトンネルが有効であることを確認するファイアウォールルールとチェック手順を扱います。
MikroTikのIPsec拠点間VPNとは？
MikroTikのIPsec拠点間VPNとは、2台のルーターの間に張られる常設の暗号化トンネルで、2つの独立したLANをレイヤー3で1つのルーティング可能なネットワークとして結合します。どちらのルーターも管理ポートを公衆インターネットに公開する必要はありません。WireGuardやOpenVPNのようなクライアントアクセス型VPN（管理者の端末1台がダイヤルインする方式）とは異なり、拠点間トンネルは常時接続でサブネット同士を結びます。ルーターAの背後にあるすべてのホストが、ルーターBの背後にある許可されたすべてのホストへ自動的に到達できます。ここでIPsecが適している理由は、事実上すべてのファイアウォールおよびルーターベンダーがサポートするオープン標準であること、RouterOSのカーネル内で動作するため良好なスループットが得られること、そしてMikroTikでは追加パッケージなしで標準搭載されていることです。
トンネルは2つのネゴシエーションで構築されます。フェーズ1（IKE）は2台のルーターを相互に認証し、安全なチャネルを確立します。フェーズ2（IPsec）は、実際にデータ通信を暗号化する鍵をネゴシエートします。両方のフェーズが両端で一致すればトンネルは確立します。アルゴリズムが1つでも食い違うと、何も告げずに失敗します。以下の手順で両側を対称に保つのはそのためです。
事前に必要なもの
RouterOS v7が動作するMikroTikルーターが2台必要です。各ルーターにはパブリックIPアドレス、または正しく動作するDDNSホスト名が必要で、さらに重複しない2つのLANサブネットが必要です。本ガイドではSite Aで192.168.10.0/24、Site Bで192.168.20.0/24を使用します。両方の拠点が192.168.88.0/24を使っている場合、ルーティングは不可能です。先に片方のアドレスを変更してください。IPsecは時刻のずれに非常に敏感なため、開始前に両方のルーターでNTPを有効にしてください。両端の時刻がずれると、セキュリティアソシエーションが期限切れになり、トンネルが切断され続けます。
その前提条件を数拠点を超える規模で管理するのは、それだけで手間のかかる作業です。フリートを運用しているなら、MKControllerは各ルーターのRouterOSバージョンと時刻ソースをトンネル切り替え前に1つのコンソールで確認させてくれるので、準備ができているか確かめるためだけに各デバイスへログインする必要はありません。
ステップ1：IKEプロファイルとピアを作成する
Site Aで、フェーズ1のプロファイルを定義し、Site Bのパブリックアドレスにピアを向けます。
/ip ipsec profile add name=to-siteB hash-algorithm=sha256 \ enc-algorithm=aes-256 dh-group=modp2048 lifetime=1d
/ip ipsec peer add name=siteB address=<SITE_B_PUBLIC_IP>/32 \ profile=to-siteB exchange-mode=ike2dh-group=modp2048はDiffie-Hellmanグループ14で、堅実で現代的なデフォルトです。exchange-mode=ike2はIKEv2を選択します。IKEv2はレガシーなmain/IKEv1モードより高速で堅牢です。両端は同じプロファイル値と同じ交換モードを使う必要があります。
ステップ2：アイデンティティ（事前共有鍵）を追加する
/ip ipsec identity add peer=siteB auth-method=pre-shared-key \ secret="<long-random-shared-secret>"長くランダムなシークレットを使い、SSH鍵と同じように保管してください。チャットメッセージに書くのは避けます。同じシークレットを両方のルーターに設定します。
ステップ3：フェーズ2プロポーザルを定義する
/ip ipsec proposal add name=to-siteB auth-algorithms=sha256 \ enc-algorithms=aes-256-cbc pfs-group=modp2048Perfect Forward Secrecy（pfs-group）は、鍵の再生成のたびに新しい鍵素材を使うことを意味します。そのため鍵が漏洩しても過去の通信が露出することはありません。フェーズ1と同様、アルゴリズムは両端で一致していなければなりません。
ステップ4：トンネルポリシーを作成する
ポリシーは、どの通信を暗号化するかをRouterOSに伝えます。つまりローカルLANからリモートLANへの通信です。
/ip ipsec policy add peer=siteB tunnel=yes \ src-address=192.168.10.0/24 dst-address=192.168.20.0/24 \ proposal=to-siteB action=encrypttunnel=yesこそが、これをホスト間ではなく拠点間にする要素です。元のパケットが丸ごとカプセル化されるため、2つのLANは透過的に通信できます。
ステップ5：NATバイパスルールを追加する（誰もが忘れるステップ）
ここでほとんどの最初の試みが失敗します。ルーターにはすでに、送信されるLAN通信の送信元アドレスを書き換えるmasqueradeルールがあります。それがIPsecより先に適用されると、リモート側は送信元がポリシーと一致しないパケットを受け取り、破棄します。トンネル向けの通信がNATを回避するよう、masqueradeの上にacceptルールを追加します。
/ip firewall nat add chain=srcnat action=accept place-before=0 \ src-address=192.168.10.0/24 dst-address=192.168.20.0/24place-before=0はルールをsrcnatチェーンの最上部に配置します。これは必須です。masqueradeの後に置かれたバイパスルールは何の効果もありません。
ステップ6：ファイアウォールを開放して確認する
トンネルが確立できるよう、inputチェーンでIKEとNAT-Tのポートに加えてESPプロトコルを許可します。どちらかの拠点が別のNATデバイスの背後にある場合は特に重要です。
/ip firewall filter add chain=input protocol=udp dst-port=500,4500 action=accept/ip firewall filter add chain=input protocol=ipsec-esp action=accept続いて、トンネルが確立していることを確認します。
/ip ipsec active-peers print/ip ipsec policy print正常なトンネルでは、アクティブなピアと、ph2-stateがestablishedと表示されるポリシーが見えます。一方のLAN上のホストからもう一方のLAN上のホストへpingを実行すれば、エンドツーエンドの到達性を確認できます。
Site Bで設定をミラーリングする
Site Bでは、アドレスを逆にしてすべての手順を繰り返します。ピアはSite AのパブリックIPを指し、ポリシーとNATバイパスはsrc-address=192.168.20.0/24とdst-address=192.168.10.0/24を使います。プロファイル、プロポーザル、アイデンティティのシークレット、IKEv2モードは同一のままです。両側が一致すると、フェーズ1とフェーズ2が完了し、トンネルが確立します。
セキュリティと運用のヒント
RouterOSにパッチを当て続けてください。最近のリリースにはIPsec/IKEv2のピア証明書照合に関わる修正が含まれており、前四半期に動いていたトンネルもアップグレードのたびに再テストする価値があります。レガシーなIKEv1のデフォルトよりも、PFS付きのIKEv2を選んでください。可能であれば、トンネル数が増えるにつれて共有シークレットから証明書認証へ移行してください。事前共有鍵が1つ漏れると、それを共有するすべての拠点に影響が及ぶためです。そしてトンネルの状態は、実際に見ている場所へログしてください。停止した拠点間リンクは、誰かが対向のLANへアクセスしようとして失敗するまで気づかれません。
フリート運用では、時刻のずれやWANの瞬断のあとに静かに切断されるIPsecトンネルは、まさに自分より先に顧客が気づく類の障害です。MKControllerはそのギャップを埋めます。デバイス側にパブリックIPもポートフォワーディングも必要としない安全なアウトバウンドトンネル経由で各ルーターを監視し、設定のバージョン管理されたバックアップを保持するので、誤った編集のあとでも動いていたIPsecブロックを差分表示して復元できます。またリンクダウンのイベントで、電話が鳴る前にチケットを起票できます。トンネル設定そのものについては、MikroTikのNATのガイドで、ここで回避しているmasqueradeルールを解説しています。2つのLANを結合するのではなく1台のルーターに到達したい場合は、CGNAT背後のリモート管理とWireGuardによるリモート管理の解説もご覧ください。
トンネルを一つ屋根の下にまとめる
IPsecは2つの拠点をきれいに接続しますが、成長するISPやMSPはすぐに数十のトンネル、鍵、ファイアウォールルールを同期し続けることになります。そして手作業の編集はすべて、リモート拠点から自分を締め出す機会になり得ます。MKControllerはまさにその規模のために作られています。集中型のフリート管理、ポートを公開しない安全なリモートアクセス、設定履歴とバックアップ、ファイアウォールとポリシー変更のフリート全体への配信により、トンネルのテンプレートはルーターごとに打ち直すのではなく一度で展開できます。MikroTikを大規模に運用するオペレーターは、デバイスごとのSSHに費やしていた午後を、変更あたり数クリックに変えるためにこれを使っています。