GRETAP（L2 over GRE）のトンネルが通らないとき、原因として多いのは「GRE パケットがファイアウォールや NAT で落ちている」「MTU が合わずに大きなパケットだけ消えている」「両端の設定がかみ合っていない」の3つです。この記事では、Linux の ip コマンドと tcpdump を使い、外側（下回りのネットワーク）から内側（トンネル内の通信）へ順に確認していく手順を、起きやすい原因の順に説明します。
GRETAP の仕組みを押さえる
GRETAP は、イーサネットフレームをそのまま GRE で包み、IP ネットワーク越しに運ぶトンネルです。通常の GRE トンネル（Linux では gre タイプ）が IP パケットを運ぶ L3 トンネルなのに対し、GRETAP は L2 のフレームを運ぶため、離れた2拠点を同じセグメントのようにブリッジできます。
障害対応で重要な特徴は次のとおりです。
- GRE は TCP でも UDP でもなく、IP プロトコル番号 47 で運ばれる。「ポート開放」の発想では許可できない
- GRE にはポート番号がないため、NAT 越えが苦手
- 外側の IP ヘッダー（20 バイト）、GRE ヘッダー（4 バイト、キー使用時は +4）、内側のイーサネットヘッダー（14 バイト）が加わるので、内側で使える MTU が小さくなる
- GRE 自体には暗号化がない
構成の基本形は次のとおりです（アドレスは例です）。
# 拠点A側（ローカル 192.0.2.1、相手 198.51.100.1）
sudo ip link add gretap1 type gretap local 192.0.2.1 remote 198.51.100.1 ttl 64
sudo ip link set gretap1 up
sudo ip link set gretap1 master br0まずトンネルの状態を確認する
最初に、トンネルインターフェースが存在し、意図した設定になっているかを見ます。
ip -d link show gretap1
ip -s link show gretap1
lsmod | grep greip -d link show の出力に gretap remote ... local ... が表示され、それが相手側の設定と対になっているかを確認します。ip -s link show では送受信のパケット数を見ます。送信（TX）は増えるのに受信（RX）が 0 のままなら、自分側からは送れているが相手からのパケットが届いていない、という切り分けができます。インターフェースが作れない場合は、カーネルモジュール（ip_gre）が読み込めない環境か、コンテナなど権限が制限された環境の可能性があります。
原因1：GRE パケットが途中で落ちている
もっとも多い原因です。外側のインターフェースで GRE パケットが出入りしているかを、両端で同時に確認します。
# 外側の NIC（例: eth0）で GRE を観察
sudo tcpdump -ni eth0 ip proto 47自分側で送信は見えるのに、相手側の tcpdump に何も出ない場合、途中で落ちています。確認するのは次の場所です。
- ホストのファイアウォール：nftables や iptables、firewalld で、相手の IP からのプロトコル 47 を許可しているか。ポート番号の指定では許可できない
- クラウドのセキュリティグループやネットワーク ACL：プロトコル番号を指定した許可ルールが作れるか、そもそもその環境で GRE が通るかは事業者によって異なる。提供元のドキュメントで確認する
- 途中のルーターや UTM：GRE を通さない設定になっている機器がないか
許可するときは、相手の IP アドレスに限定してください。GRE はなりすましに弱いため、誰からでも受け付ける設定は避けます。nftables なら次のような形です。
sudo nft add rule inet filter input ip saddr 198.51.100.1 meta l4proto gre acceptチェーンの末尾に明示的な drop ルールがある場合、add で追加したルールはその後ろに入って効きません。その場合は insert を使うか、ルールの位置を指定してください。
原因2：NAT の内側にある
片側（または両側）がブロードバンドルーターやクラウドの NAT の内側にある場合、local に指定すべきアドレスと、相手から見えるアドレスが違います。
localにはそのホストが実際に持っているアドレス（NAT の内側ならプライベート IP）を指定する- 相手側の
remoteには、NAT の外側から見えるグローバル IP を指定する - NAT 機器が GRE を内側のホストへ転送できるか確認する。家庭用ルーターでは対応していないことが多い
NAT をはさむ構成でどうしても通らない場合は、UDP で運ぶ VXLAN や、暗号化も兼ねる WireGuard を下回りに使い、その上で L2 を延ばす構成を検討したほうが、運用は安定しやすくなります。
原因3：MTU の不一致（小さい通信は通るのに大きいと止まる）
「ping は通るのに、SSH のログイン後や HTTPS の表示で止まる」「WordPress の管理画面が途中までしか表示されない」といった症状は、MTU 問題の典型です。キーなしの GRETAP では外側 MTU 1500 から 38 バイトが差し引かれ、内側は 1462 バイトになります。
大きさを指定して、断片化禁止で ping を送ると確認できます（Linux の場合）。
# 1462 - IPヘッダー20 - ICMPヘッダー8 = 1434
ping -M do -s 1434 10.0.0.2
ping -M do -s 1472 10.0.0.2 # こちらは失敗するのが正常1434 で通り 1472 で失敗するなら、トンネルの MTU 自体は計算どおりです。問題は、ブリッジの先にある端末が 1500 のまま送っていることです。対策は次のいずれかです。
- トンネルを通る端末やブリッジ側のインターフェースの MTU を、トンネルに合わせて下げる
- 下回りのネットワークでジャンボフレームが使えるなら、外側の MTU を上げる
- 転送するルーターで TCP の MSS を調整する
MSS の調整は、iptables では次の書き方がよく使われます。
sudo iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtuただし、L2 でブリッジしているフレームは通常ルーティングされないため、この設定が効く場所は構成によって変わります。ブリッジ構成では、端末側の MTU をそろえる方法のほうが効果を確認しやすい場合が多いです。
原因4：両端の設定のかみ合わせ
localとremoteが両端で入れ替わった対になっているかkeyを使う場合、両端で同じ値か（ikey/okeyを個別に指定している場合は、片側の okey と相手の ikey が一致しているか）- トンネルインターフェースとブリッジの両方が up になっているか
- トンネルがブリッジに参加しているか（
bridge linkで確認）
ブリッジのフォワーディングデータベースを見ると、トンネルの向こう側の MAC アドレスを学習できているか分かります。
bridge link
bridge fdb show dev gretap1相手側の MAC アドレスが表示されていれば、L2 の通信はトンネルを通っています。
原因5：L2 ループ
2拠点の間に GRETAP 以外の経路（別のトンネルや専用線）もあると、L2 のループが起きてブロードキャストストームになることがあります。トンネルを up にした直後に両拠点のネットワークが重くなった場合は、まずトンネルを down にして状況が戻るか確認します。冗長な経路がある構成では、ブリッジで STP を有効にするか、経路を1本にしてください。
運用上の注意
GRE には暗号化がないため、インターネット越しに業務データを流すなら、IPsec で保護するか、WireGuard などの暗号化トンネルに切り替えることを検討してください。設定変更は、ルーティングやブリッジの状態を記録してから行い、遠隔拠点の作業では、トンネル以外の管理経路（コンソールや別回線）を確保しておきます。ip link で作ったトンネルは再起動で消えるため、永続化は systemd-networkd や NetworkManager、各ディストリビューションのネットワーク設定ファイルで行います（2026年10月現在、設定ファイルの書式はディストリビューションとバージョンによって異なります）。
まとめ
- GRETAP は L2 フレームを GRE で運ぶトンネル。GRE は IP プロトコル 47 で、ポート番号がない
- まず
ip -s linkの送受信カウンタで「どちら向きが止まっているか」を切り分ける - 原因の多くは、ファイアウォールやクラウドでの GRE 遮断、NAT、MTU 不一致
- MTU は
ping -M do -sで確かめ、端末側の MTU 調整か MSS 調整で対処する - 暗号化がないため、インターネット越しでは IPsec や WireGuard との組み合わせを検討する