前提条件

当該ネットワークは頭と効率が悪い変態ネットワークである。
自宅でオンプレ運用していたサーヴァーをクラウドに移設したが使い勝手を優先してクラウド移行前の環境をVPNを使いそのままクラウドまで持っていった形になっている。
そのためOSPFとかもクラウドまで行っているというアレなネットワークになっている。
さらに本ネットワークは固定IP回線と動的IP回線によるマルチホーム構成になっている。
ちなみに固定IPは単なる趣味の実験のために取得してある。色々な実験をするには固定IPが便利だから。
ConoHa VPSへのVPN接続は動的IPの方が回線が早いのでこっちを経由で接続している。

適切なMTUを設定する

パケットを効率良く転送するため適切なMTUを設定する必要がある。
回線はNTT東日本のフレッツ光ネクストなので回線自体のMTUは1454である。
本ネットワークはConoHa-VPSまでIPsecで結んでいる。
IPsecはNATトラバーサル、暗号化はAES、認証はSHA1なのでIPsecトンネルのMTUは1374、MSSは1334となる。
よって以下のようにIX2025に設定した。

interface Tunnel0.0
  tunnel mode ether-ip ipsec
  ip mtu 1374
  no ip address
  ip tcp adjust-mss 1334
  ipsec policy tunnel ipsec-map pre-fragment out
  bridge-group 1
  no shutdown

なんかおかしい

確認のためにConoHa-VPS(10.0.0.3)に向ってフラグメントなしで設定したMTU(1374)を超えたデータサイズ1347byte[=1375-20(IPヘッダ)-8(ICMPヘッダ)]でpingを打つとなぜかpingが通過した。フラグメント禁止しているのにだ。

shin@yui[16]%ping -M do -s 1347 10.0.0.3
PING 10.0.0.3 (10.0.0.3) 1347(1375) bytes of data.
1355 bytes from 10.0.0.3: icmp_seq=1 ttl=254 time=7.95 ms
1355 bytes from 10.0.0.3: icmp_seq=2 ttl=254 time=8.11 ms
1355 bytes from 10.0.0.3: icmp_seq=3 ttl=254 time=8.10 ms
^C
--- 10.0.0.3 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 7.951/8.054/8.113/0.127 ms

あれれれれ？

わけがわからないのでConoHa側(仮想計算機のEthernetポート)でtcpdumpを実施してwiresharkで解析してみたところ、パケットのデータ数がMTUを越えておりフラグメントされていた。

さらにVPS(OpenBSD)側のOSPFはステートがEXSTAのままFULLにならない。

shin@conoha-saki.aerg.net[3]%ospfctl show neighbor
ID              Pri State        DeadTime Address         Iface     Uptime
192.168.0.40    1   EXSTA/DR     00:00:34 10.0.0.2        tap1      -
192.168.1.42    1   FULL/BCKUP   00:00:39 10.0.0.1        tap1      00:03:31

で、IX2025のトンネルインターフェース(Tunnel0.0)の詳細を確認してみたら

conoha-gateway(config)# show interfaces Tunnel0.0 
Interface Tunnel0.0 is up
  Fundamental MTU is 0 octets
  Current bandwidth 100M b/s, QoS is disabled
   (途中省略)
  Encapsulation TUNNEL:
    Tunnel mode is ipsec (ether-ip ip)
    Tunnel is ready
    Destination address is xxx.xxx.xxx.xxx
    Source address is 10.0.1.2
    Nexthop address is 10.0.1.253
    Outgoing interface is FastEthernet1/0.0
    Interface MTU is 1422
    Path MTU is 1500
  (以下省略)

あれ？ Interface MTUが1422になっているし、Path MTUが1500になっていた。
トンネルインターフェースのMTUやMSSを設定すれば出力側(Outgoing interface)の物理インターフェース(FastEthernet1/0.0)のMTUは自動的に設定されると思っていたが、どうやら出力側の物理インターフェースでMTUをいじってやらんと駄目らしい。
逆に言えば物理インターフェースのMTUを変更すると対応するトンネルインターフェースのMTUが自動的に変更されるようだ。

そこで、出力側インターフェースのFastEthernet1/0.0にフレッツのMTU(1454)を設定した。

interface FastEthernet1/0.0
  ip address 10.0.1.2/24 
  ip mtu 1454
  no shutdown

IXシリーズの場合、物理インターフェースを設定すると、トンネルインターフェースのMTUやMSSは暗号化設定の内容により自動的に設定されるとのこと。

トンネルインターフェースを確認してみたら、今度は目論見どおりにMTUが1374になっていた。

conoha-gateway(config)# show interfaces Tunnel0.0 
Interface Tunnel0.0 is up
  Fundamental MTU is 0 octets
  Current bandwidth 100M b/s, QoS is disabled
  (途中省略)
  Encapsulation TUNNEL:
    Tunnel mode is ipsec (ether-ip ip)
    Tunnel is ready
    Destination address is xxx.xxx.xxx.xxx
    Source address is 10.0.1.2
    Nexthop address is 10.0.1.253
    Outgoing interface is FastEthernet1/0.0
    Interface MTU is 1374
    Path MTU is 1454
  (省略)

試しにMTUサイズを越えたデータサイズでpingを打ってみると、

yui%ping -M do -s 1347 10.0.0.3
PING 10.0.0.3 (10.0.0.3) 1347(1375) bytes of data.
^C
--- 10.0.0.3 ping statistics ---
4 packets transmitted, 0 received, +4 errors, 100% packet loss, time 3033ms

今度は疎通しないのでOKっぽい。

OSPFのためのMTU再設定

OSPFは互いのインターフェースのMTUが違うとFULLステートにならないのでMTUの再設定をする。

IX2025側

IX2025はOSPF設定で指定されているインターフェース側でおこなう。
VPS側にOSPFを流しているインターフェースを確認する。

ip router ospf 1
  router-id 192.168.0.40
  area 0
  area 300
  area 301
  network FastEthernet0/0.0 area 0
  network FastEthernet1/0.0 area 301
  network BVI1 area 300

VPS側にOSPFを流しているインターフェースはブリッジインターフェースのBVI1である。
従って設定すべきは物理インターフェース(FastEthernet0/1.0)ではなくブリッジインターフェースであるBVI1なので以下のように設定する。

interface BVI1
  ip address 10.0.0.2/24 
  ip mtu 1347
  (途中省略)
  bridge-group 1
  no shutdown

OpenBSD側のMTU設定

OpenBSD側のMTUもIX2025側と同じ値にしておかないとOSPFでFULLにならない。
OpenBSD側ではSoftEtherでIPsecを処理していて、tapインターフェース(tap1)を介してOpenBSDネットワークと接続している。
以下のようにしてOpenBSDのtapインターフェースにMTUを設定する。

ifconfig tap1 mtu 1374

起動時に自動的に設定されるように/etc/hostname.tap1にも設定しておく。

inet 10.0.0.3  255.255.255.0
mtu 1338

Fortigate側のMTU設定

自宅側でVPNと同じセグメントにある固定IP用のFortigate50E側インターフェースもOSPFを喋っているので同様にMTUの再設定する。
mssを設定する必要があるかわからんけど設定しておいた。

# config system interface
(interface) # edit wan2
(wan2) # set mtu-override enable
(wan2) # set mtu 1374
(wan2) # next
(interface) # end

それでも何かおかしい。

これ良いと思ったので最終確認でMTUぴったりのデータサイズ1346[=1374-20(IPヘッダ)-8(ICMPヘッダ)]でVPSへpingを打ってみるが応答が無い。

shin@yui[7]%ping -M do -s 1346 10.0.0.3
PING 10.0.0.3 (10.0.0.3) 1346(1374) bytes of data.
^C
--- 10.0.0.3 ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 3029ms

なんで通過せんの？
じゃぁ、いくつなら疎通するのか？
データサイズを減らして行ったら1310バイトで疎通した。

root@yui:/home/shin# ping -M do -s 1310 10.0.0.3
PING 10.0.0.3 (10.0.0.3) 1310(1338) bytes of data.
1318 bytes from 10.0.0.3: icmp_seq=1 ttl=254 time=6.57 ms
1318 bytes from 10.0.0.3: icmp_seq=2 ttl=254 time=6.73 ms
1318 bytes from 10.0.0.3: icmp_seq=3 ttl=254 time=6.30 ms
1318 bytes from 10.0.0.3: icmp_seq=4 ttl=254 time=6.40 ms
^C
--- 10.0.0.3 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3005ms
rtt min/avg/max/mdev = 6.301/6.502/6.733/0.165 ms

ということはMTUは1338(=1310+28)なのか?

後半に続く。