LinuxにおけるGREおよびIPIPトンネルの設定：VPN不要で軽量なSite-to-Site接続を実現 – ITFROMZERO

Table of Contents

複雑なVPN不要、迅速なSite-to-Site接続

データセンターのサーバーとオフィスのサーバーを接続して、データベースの同期や内部ファイルの転送を行う必要がありますか？ OpenVPNのような重いシステムをインストールする代わりに、GRE (Generic Routing Encapsulation) や IPIP (IP-over-IP) は、より「迅速かつ軽量」な選択肢となります。

これら両方のプロトコルはLinuxカーネルレベルで直接動作します。そのため、パケット処理速度が非常に速く、CPUリソースの消費もわずかです。私はこれらを、パブリックなインターネット環境を貫通する「専用의データパイプ（プライベートパイプ）」のようなものだと考えています。

5分でできるGREトンネルの設定

まずは具体的な例から始めましょう。接続が必要な2つのノードがあると仮定します：

サーバーA（ハノイ）: パブリックIP 1.1.1.1、トンネルIP 10.0.0.1
サーバーB（サイゴン）: パブリックIP 2.2.2.2、トンネルIP 10.0.0.2

サーバーAの設定：

# gre0という名前のトンネルインターフェースを作成
sudo ip tunnel add gre0 mode gre remote 2.2.2.2 local 1.1.1.1 ttl 255
# 内部IPアドレスを割り当て
sudo ip addr add 10.0.0.1/30 dev gre0
# インターフェースを有効化
sudo ip link set gre0 up

サーバーBの設定：

sudo ip tunnel add gre0 mode gre remote 1.1.1.1 local 2.2.2.2 ttl 255
sudo ip addr add 10.0.0.2/30 dev gre0
sudo ip link set gre0 up

設定が完了したら、サーバーAから ping 10.0.0.2 を試してみてください。遅延が安定しており、パケットロスがなければ、トンネルは準備完了です。

GREかIPIPか：どちらが最適な選択肢か？

これら2つのプロトコルの違いは、カプセル化の能力とパフォーマンスにあります：

GRE: 非常に柔軟です。IPv6やマルチキャストを含む、ほとんどのレイヤー3プロトコルをカプセル化できます。OSPFを動かして両端のルートを自動更新する予定があるなら、GREが必須の選択となります。
IPIP: シンプルで軽量です。IPv4の中にIPv4を包むだけです。最大の利点はオーバーヘッドの低さです。IPIPのヘッダーは20バイトですが、GREは24バイト消費します。純粋なIPv4接続で帯域幅を最大限に活用したい場合は、IPIPの方がわずかに優れています。

IPIPに変更するには、上記のコマンドの mode gre を mode ipip に変えるだけです。

2つのLANセグメントを疎通させるためのルーティング

最終的な目標は、LAN A (192.168.1.0/24) のクライアントが LAN B (192.168.2.0/24) のクライアントと通信できるようにすることです。

サーバーAにて： sudo ip route add 192.168.2.0/24 dev gre0

サーバーBにて： sudo ip route add 192.168.1.0/24 dev gre0

特に注意すべき点として、IP Forwardingを有効にする必要があります。そうしないと、サーバーはパケットを受信しても転送しません：

sudo sysctl -w net.ipv4.ip_forward=1

実践的な経験：頭を悩ませるMTUの問題

以前トンネルをセットアップした際、Pingは非常にスムーズでSSHでのコマンド入力も問題ありませんでした。しかし、大容量ファイルをダウンロードしたり、管理Webページを開こうとしたりすると、接続がフリーズしてしまう現象が起きました。

<a href="https://itfromzero.com/ja/network/tcpdump%e3%81%a8wireshark%e3%82%92%e4%bd%bf%e3%81%a3%e3%81%9f%e3%83%8d%e3%83%83%e3%83%88%e3%83%af%e3%83%bc%e3%82%af%e3%83%88%e3%83%a9%e3%83%95%e3%82%a3%e3%83%83%e3%82%af%e8%a7%a3%e6%9e%90%e5%85%a5.html">tcpdump</a> で調査した結果、パケットがサイズオーバーでドロップされていることが判明しました。標準のパケットは1500バイトです。GREの24バイトのヘッダーが加わると1524バイトになり、インターネット上の途中のルーターによって拒否されてしまいます。

根本的な解決策： MTUを1400に下げ、MSS Clampingを使用します。

# ヘッダー用にMTUを下げて空きを確保
sudo ip link set dev gre0 mtu 1400

# TCP接続にサイズを自動調整させる（MSS Clamping）
sudo iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

上記の TCPMSS コマンドは非常に重要です。これにより、ラグや転送速度低下の主な原因となるパケットの断片化（フラグメンテーション）を防ぐことができます。

Netplanによる設定の永続化

ip tunnel コマンドによる設定は、再起動すると消えてしまいます。Ubuntu/Debian系では、/etc/netplan/01-netcfg.yaml ファイルに記述して、起動時に自動的に反映されるようにします：

tunnels:
  gre0:
    mode: gre
    local: 1.1.1.1
    remote: 2.2.2.2
    addresses:
      - 10.0.0.1/30
    routes:
      - to: 192.168.2.0/24
        via: 10.0.0.2

セキュリティに関する注意点

GREとIPIPはデフォルトで暗号化されていません。データはインターネット上をプレーンテキストで流れます。機密情報を送信する場合は、このトンネルをIPsecで包むべきです。

最低限、iptables を使用して、GREポートへの接続を許可されたIPのみに制限してください：

sudo iptables -A INPUT -p gre -s 2.2.2.2 -j ACCEPT
sudo iptables -A INPUT -p gre -j DROP

クイックまとめ

動的ルーティングが必要なネットワークには GRE を、帯域幅を節約したい場合は IPIP を使用する。
パケットが途中でドロップされないよう、常に MTU 1400 を設定する。
TCP MSS Clamping は、トンネル経由で動作するWeb/データベースアプリケーションの救世主である。
外部からの攻撃を防ぐため、ファイアウォールの制限を忘れない。

トンネルの構築自体は数分で終わりますが、高負荷下で安定して動作するように最適化することこそが挑戦です。この共有が、私がかつて経験したMTUに関する「初歩的な」ミスを避ける助けになれば幸いです。