前書き
突然ですが、拙宅はNTT西のVDSL回線です(ドコモ光OCN)。
マンション備え付けの JPIX系IPoE無料インターネット回線もある のですが、3年ぐらい前に上流ルーターの容量逼迫で、最大66.7%ものパケロスが起きる 事態に遭遇して、嫌々渋々VDSLを引きました。
導入当時100Mbps（確実に通る）か10Gbps（調査承ります）かの2択で、 マンションの管理会社に10ギガ回線通せるか調査だけでもさせてくれないか交渉したんですがダメでした。
で、自宅サーバーの入り口にしているVPSとは LACP on VXLAN on WireGuard で冗長化構成を取って接続しています。
現在はJPIX系の方もパケロスはほぼなくなったようですが、惰性でVDSLを維持しています。
ですが、この構成を取ると 兎に角MTUサイズがガリガリ削られます。
これに起因する問題はまあ色々とありますが、今回は この構成を改めてMTUサイズを1420まで拡大するための予備調査 として、
- VPSとの間に貼っているWireGuard上にOSPF + BIRD + BFDを通し
- VPSのグローバルIPアドレスを使って
- 100Mbps律速のVDSL回線とJPIX系無料インターネット回線をロードバランシングして
- iperf3やスピードテストで150Mbps以上を得る
という構成にチャレンジします。
用意するもの
1. 回線速度200Mbps以上のVPS(日本に割り当てられているグローバルIPでホストされているものが良い)
今回は出口にVPSを使用します。
当然、回線速度はVDSLを超える速度(最低でも200Mbps)のものが必要です。
日本でホストされているVPSやVPCで、多分日本に割り当てられているグローバルIP でホストされていて、 回線速度200Mbpsを発揮可能なサービス はおおよそ以下の通りかと思います。
- KAGOYA CLOUD VPS(今回使用、実測230~285Mbps)
- ConoHa VPS(300Mbps帯域拡張オプション使用時)
- ABLENET VPS(200Mbps共有回線)
- XServer VPS(16GB以上のプランで300Mbps)
- WebARENA Indigo(4GB以上のプランで500Mbps以上)
その他にもあるかもしれませんが、多分有名所はこれぐらいかなと。
この中で IPv6に対応していないのはXServer VPSのみ なので、ポート転送が面倒なので除外。
地理的に拙宅に近くないWebARENA Indigoと、ホストサーバー所在地不明で地理関係不明、帯域拡張オプションがお高いConoHa VPS も除外。
地理的に拙宅に近いABLENET VPS と、次点で拙宅に近いKAGOYA CLOUD VPS を比較して、 新規契約の面倒さ 使い慣れていておおよその発揮速度が知れている KAGOYA CLOUD VPS を今回は選択しました。
なお、今回は拙宅と既にWireGuardの接続が取れているインスタンスを流用しましたが、多分、専用インスタンスを新たに取った方が色々と悩まなくて済んだと思います。
なお、日本国内IPに限らなければ Vultr とか Akamai(Linode) や Oracle Cloud Infrastructure(OCI) などがあるのですが、国外判定されて利用できないサービスに遭遇する恐れがあります(ドコモメールとか)。
ちなみにVultrのインスタンスはIPv4が謎に米国西海岸を通って日本に戻ってきてることがあります。
あと、実際にこの構成でKAGOYA CLOUD VPSを出入り口にすると、 国外(香港)判定を受けてGoogleのサービスが使えなくなります。具体的にはGeminiとか。なんでや日本のサービスプロバイダやろ🥺
2. (ホワイトボックス)Linuxルーター
拙宅はLinuxルーターを自作して運用していますので、ここは問題ありません。
難しい場合はOpenWrtでも出来なくはないけど。
今回はルーターとVPS、両方とも全部Debian13で統一しています。
3.WAN回線×2本(IPv6対応)
当たり前ですが、今回は2本のWAN回線を使って冗長化＆ロードバランシングする話ですので、WAN回線が2つないと話になりません。
片方がNTT系なら片方はJPIX系のIPv6、みたいに上流回線が別のVNEだとなお良い。
実際の作業
1.VPSのインスタンスが立ち上がったら、最低限の初期設定は済ませておく
VPSのインスタンスが立ち上がったら、サクッとアップデートして、最低限のFirewallは設定しておきましょう。
2.VPSのネットワーク設定をNetplanに切り替える
ぶっちゃけ大方の基礎的なネットワーク設定を一元管理したいので Debian13をKAGOYA CLOUD VPSで立ち上げるとネットワーク設定がNetplanでは管理されていないので、netplan.io と wireguard を先にインストールしてYAMLを書き、 /etc/network/interface の設定はコメントアウトするか移動します。
この時、VPS側のWireGuardの設定は、例えば以下のようにします(WAN回線の本数分だけWireGuardインターフェイスを書いてください)。
network:
version: 2
renderer: networkd
tunnels:
<WireGuardインターフェイス名>:
addresses: [ <VPS側のWireGuard内プライベートIPv4アドレス>/30, '<VPS側のWireGuard内ULA>/64', '<VPS側のWireGuard内Link-Localアドレス>/64' ]
link-local: [ ipv6 ]
key: '<VPS側のプライベート鍵>'
local: '<VPS側のグローバルIPv6アドレス>'
mode: wireguard
optional: true
peers:
- allowed-ips: [ <WireGuard内プライベートIPv4セグメント>, <ルーター側LANのIPv4セグメント>, 224.0.0.0/4, '<WireGuard内ULAセグメント>', '<ルーター側LANのULAセグメント>', 'fe80::/64', 'ff00::/8' ]
keepalive: 25
keys:
public: '<ルーター側の公開鍵>'
port: <VPS側のWireGuard1 Listenポート>
routes:
- to: <ルーター側LANのIPv4セグメント>
via: <ルーター側WireGuard内IPv4アドレス>
metric: 100
- to: '<ルーター側LANのULAセグメント>'
via: '<ルーター側WireGuard内IPv6アドレス>'
metric: 100
WireGuardは本来Point-to-Point通信なので、/32(IPv4)と/128(IPv6)の固定IPでも通信が到達する筈ですが、どうも NetplanでWireGuardを管理する場合、きちんと（？）アドレス範囲を決めておいて、allowed-ipsにはアドレス範囲を設定しないといけない ようです（理不尽）。
この時、VPS側のallowed-ipsには以下の値の設定が必要です。
- WireGuard内プライベートIPv4セグメント
- ルーター側LAN内のIPv4セグメント
- WireGuard内ULAセグメント
- ルーター側LAN内のULAセグメント
- fe80::/64 (リンクローカルアドレス)
- ff00::/8 (マルチキャストアドレス)
何故、 WireGuardなのにリンクローカルアドレスとマルチキャストアドレスを持たせたり許可したりしないといけない のかと言うと、これは後述しますが、 OSPF v3がリンクローカルアドレスとマルチキャストアドレスでしかBFDパケットの遣り取りをしない 仕様になっているからです。
で、その理屈で言うと WireGuard内にULA付与しなくてもリンクローカルアドレス振ったならそれで通信できるんじゃね？ と思うのですが、何故か上手く動かなかったので取り敢えず騙されたと思って振ってください。
3.ルーター側のNetplanに、VPSとの接続設定を書く
ポリシーベースルーティング(PBR)が無いと複数のWANから、同じIPの別のポート宛にWireGuardを張ることが出来ません。
また、WAN回線の本数分だけWireGuardインターフェイスを書いてください(横着して一つのインターフェイスで複数のピアを張ろうとしない)。
network:
version: 2
renderer: networkd
ethernets:
<WAN回線1>:
match:
macaddress: 'AA:BB:CC:DD:EE:FF'
optional: true
routes:
- to: ::/0
via: <WAN回線1の対向ルーターのリンクローカルアドレス>
mark: <WireGuardインターフェイス1に設定するのと同じ値>
metric: 2
routing-policy:
- to: <VPSのグローバルIPv6アドレス>
table: <全体で一意の値>
mark: <WireGuardインターフェイス1に設定するのと同じ値>
set-name: 'WAN1'
tunnels:
<WireGuardインターフェイス1>:
addresses: [ <ルーター側のWireGuard内プライベートIPv4アドレス>/30, '<ルーター側のWireGuard内ULA>/64', '<ルーター側のWireGuard内Link-Localアドレス>/64' ]
link-local: [ ipv6 ]
key: '<ルーター側のWireGuardプライベート鍵>'
link: <ルーター側のWAN1インターフェイス名>
local: '<ルーター側のWAN1 IPv6アドレス>'
mark: <WAN回線1のrouting-policyのmarkに設定したmarkと同じ値>
mode: wireguard
optional: true
peers:
- allowed-ips: [ <WireGuard内プライベートIPv4セグメント>/30, 0.0.0.0/0, 224.0.0.0/4, '<WireGuard内ULAセグメント>', 'fe80::/64', '::/0' ]
endpoint: '[VPS側のWAN1 IPv6アドレス>]:<VPS側のWireGuard1 Listenポート>'
keepalive: 25
keys:
public: '<VPS側のWireGuard公開鍵>'
port: <ルーター側のWireGuard1 Listenポート>
routes:
- to: 0.0.0.0/0
via: <VPS側のWireGuard内IPv4アドレス>
metric: 100
- to: ::/0
via: '<VPS側のWireGuard内IPv6アドレス>'
metric: 100
ルーター側は WireGuardのPBRのメトリックは2として優先度を上げておきます。
それ以外のトラフィックは原則としてWireGuardの先に居るVPSを通したいので、 WireGuard内にデフォルトゲートウェイを通して、メトリックは100に下げておきます。
allowed-ipsは 常識的に考えるなら0.0.0.0/0と::/0が入っていれば動きそうなものですが、何故か動かなかったので、別途必要に応じて必要な範囲設定をしています。
4.VPSとルーターに、BIRDをインストールする
Debian13だとbird3が入ります(普通なら)。試行錯誤の段階では他にも幾つかソフトを入れていましたが、多分bird3だけで良いです。
root@Debian13:~# apt install bird3
4.1.トラフィックモニターを入れておく
何故かきちんとWireGuardのトラフィックをキャッチ出来ないので、物理WANインターフェイスのトラフィックを監視する必要がありましたが、speedometerを入れておくとトラフィックの分散を確認できて便利です。
root@Debian13:~# apt install speedometer
5.VPSとルーターのsysctlとUFWのパラメーターを弄っておく
5.1.sysctlのパラメーター設定
/etc/sysctl.d/ に99-sysctl.conf を作成します。値はVPSとルーター、共に共通です。
net.core.default_qdisc = fq
net.core.netdev_max_backlog = 5000
net.core.rmem_max = 16777216
net.core.wmem.max = 16777216
net.ipv4.tcp_rmem = 4096 65536 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216
net.ipv4.tcp_congestion_control = bbr
net.core.somaxconn = 32768
net.ipv4.fib_multipath_hash_policy = 1
5.2.UFWのパラメーター設定
あとUFWのパラメーターも弄っておきます。
#
# Configuration file for setting network variables. Please note these settings
# override /etc/sysctl.conf and /etc/sysctl.d. If you prefer to use
# /etc/sysctl.conf, please adjust IPT_SYSCTL in /etc/default/ufw. See
# Documentation/networking/ip-sysctl.txt in the kernel source code for more
# information.
#
# Uncomment this to allow this host to route packets between interfaces
# <ここからアンコメント>
net/ipv4/ip_forward=1
net/ipv6/conf/default/forwarding=1
net/ipv6/conf/all/forwarding=1
# <ここまでアンコメント>
# Disable ICMP redirects. ICMP redirects are rarely used but can be used in
# MITM (man-in-the-middle) attacks. Disabling ICMP may disrupt legitimate
# traffic to those sites.
net/ipv4/conf/all/accept_redirects=0
net/ipv4/conf/default/accept_redirects=0
net/ipv6/conf/all/accept_redirects=0
net/ipv6/conf/default/accept_redirects=0
# Ignore bogus ICMP errors
net/ipv4/icmp_echo_ignore_broadcasts=1
net/ipv4/icmp_ignore_bogus_error_responses=1
net/ipv4/icmp_echo_ignore_all=0
# Don't log Martian Packets (impossible addresses)
# packets
net/ipv4/conf/all/log_martians=0
net/ipv4/conf/default/log_martians=0
#net/ipv4/tcp_fin_timeout=30
#net/ipv4/tcp_keepalive_intvl=1800
# Uncomment this to turn off ipv6 autoconfiguration
#net/ipv6/conf/default/autoconf=1
#net/ipv6/conf/all/autoconf=1
# Uncomment this to enable ipv6 privacy addressing
#net/ipv6/conf/default/use_tempaddr=2
#net/ipv6/conf/all/use_tempaddr=2
5.3.UFWのルール設定
UFWはOSPFのIPプロトコル89番を解釈出来ません(正確には語弊があるかもしれないが、実際問題UFWのコマンドでは扱えない)。
WireGuard内を流れるパケットはピア同士しか存在しない信頼された空間であるため、トンネルインターフェースからの受信トラフィックをまるごと許可するのがシンプル。
ただし、『それで本当にええんか？』という疑問は尽きない。
root@Debian13:~# ufw default deny
root@Debian13:~# ufw default deny forward
root@Debian13:~# ufw allow in on <WireGuardインターフェイス名1> comment 'Allow all WireGuard <WireGuardインターフェイス名1>'
root@Debian13:~# ufw allow in on <WireGuardインターフェイス名2> comment 'Allow all WireGuard <WireGuardインターフェイス名2>'
後は、トンネルに流しても良いトラフィックのFWDルールをお好みでトンネルの数だけ設定します。IPv4/IPv6両方設定が必要です。
root@Debian13:~# ufw route allow in on <LANインターフェイス名> out on <WireGuardインターフェイス名1> from <ローカルセグメント> port 32768:65535 to any port 22,80,443,465,587,993 proto tcp comment 'WireGuard1 outgoing TCP'
root@Debian13:~# ufw route allow in on <LANインターフェイス名> out on <WireGuardインターフェイス名2> from <ローカルセグメント> port 32768:65535 to any port 22,80,443,465,587,993 proto tcp comment 'WireGuard2 outgoing TCP'
5.4.TCP MSS ClampingとNAT設定
それと、TCP MSS Clampingの設定をmangleを使ってトンネル内へ流れるトラフィックに施します。
ルーター側はこんな感じ。
5.4.1.ルーター側のbefore.rules
# User Rules
*mangle
:ufw-before-mangle - [0:0]
:PREROUTING ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
# TCP MSS Clamping
-A FORWARD -j ufw-before-mangle
# WAN用
-A ufw-before-mangle -o <WireGuardインターフェイス名1> -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1380
-A ufw-before-mangle -o <WireGuardインターフェイス名2> -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1380
# その他
-A ufw-before-mangle -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
COMMIT
5.4.2.ルーター側のbefore6.rules
# User Rules
*mangle
:ufw6-before-mangle - [0:0]
# TCP MSS Clamping
-A FORWARD -j ufw6-before-mangle
# WAN用
-A ufw6-before-mangle -o <WireGuardインターフェイス名1> -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1380
-A ufw6-before-mangle -o <WireGuardインターフェイス名2> -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1380
# その他
-A ufw6-before-mangle -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
COMMIT
# NAT Rules
*nat
:PREROUTING ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
# Outgoing
# Incoming
COMMIT
NATはVPS側で処理してルーターはNexthopへパケットをNATせずに投げるだけ なので、TCP MSS Clamping入れる以外は楽ですね。
5.4.3.VPS側のbefore.rules
一方、VPS側はNAT設定が入るのと、 ルーターのWireGuard内IPからインターネットへの直接発呼を扱うことになる のでこうなります。
# User Rules
*mangle
:ufw-before-mangle - [0:0]
:PREROUTING ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
# TCP MSS Clamping
-A FORWARD -j ufw-before-mangle
-A ufw-before-mangle -o <WireGuardインターフェイス名1> -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1380
-A ufw-before-mangle -o <WireGuardインターフェイス名2> -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1380
# その他
-A ufw-before-mangle -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
COMMIT
# NAT Rules
*nat
:PREROUTING ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
# Outgoing
-A POSTROUTING -o eth0 -s <WireGuard1のルーター側IP> -j SNAT --to-source <VPSのグローバルIP>
-A POSTROUTING -o erh0 -s <WireGuard2のルーター側IP> -j SNAT --to-source <VPSのグローバルIP>
-A POSTROUTING -o eth0 -s <ローカルネットワークのセグメント> -j SNAT --to-source <VPSのグローバルIP>
# Incoming
COMMIT
5.4.4.VPS側のbefore6.rules
# User Rules
*mangle
:ufw6-before-mangle - [0:0]
# TCP MSS Clamping
-A FORWARD -j ufw6-before-mangle
# WAN用
-A ufw6-before-mangle -o <WireGuardインターフェイス名1> -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1380
-A ufw6-before-mangle -o <WireGuardインターフェイス名2> -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1380
# その他
-A ufw6-before-mangle -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
COMMIT
# NAT Rules
*nat
:PREROUTING ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
# Outgoing
-A POSTROUTING -s <WireGuard1のルーター側ULA>/128 -j SNAT --to-source [<VPSのグローバルIP>]
-A POSTROUTING -s <WireGuard2のルーター側ULA>/128 -j SNAT --to-source [<VPSのグローバルIP>]
-A POSTROUTING -s <ルーター側のLAN内ULA> -j SNAT --to-source [<VPSのグローバルIP>]
# Incoming
COMMIT
ちなみにUFWでIPマスカレードする場合、DHCPでIPが降ってきているのでなければ(つまりあらかじめ固定されている場合)、『-j MASQUERADE』よりも『-j SNAT --to-source (VPSのグローバルIP)』とした方が負荷は低いしレスポンスも良いそうです。
6.BIRDの設定を書く
徐にBIRDの設定を書きます。
6.1.ルーター側のBIRDの設定を書く
log syslog all;
router id <ルーターのIPv4アドレス>; # neighbor同士で一意のIDでなくてはなりません。
protocol device {
scan time 10;
}
protocol direct {
ipv4;
ipv6;
}
protocol kernel {
ipv4 {
import all;
export all;
};
scan time 20;
persist;
learn;
}
protocol kernel {
ipv6 {
import all;
export all;
};
scan time 20;
persist;
learn;
}
protocol bfd {
}
protocol ospf v2 {
tick 10;
rfc1583compat yes;
ipv4 {
import all;
export filter {
if ( source = RTS_DEVICE && net ~ <LANのセグメント> ) then accept;
if net = 0.0.0.0/0 then accept;
reject;
};
};
area 0 {
interface "<VPSと接続しているWireGuardインターフェイス名1>" {
type ptp;
neighbors {
<VPSと接続しているWireGuardインターフェイス名1の対向IP>;
};
hello 1;
dead 5;
retransmit 5;
priority 0;
cost 10;
bfd yes;
};
interface "<VPSと接続しているWireGuardインターフェイス名2>" {
type ptp;
neighbors {
<VPSと接続しているWireGuardインターフェイス名2の対向IP>;
};
hello 1;
dead 5;
retransmit 5;
priority 0;
cost 10;
bfd yes;
};
};
}
protocol ospf v3 {
tick 10;
rfc1583compat yes;
ipv6 {
import all;
export filter {
if ( source = RTS_DEVICE && net ~ <LAN内ULAプリフィックス>/64 ) then accept;
if net = ::/0 then accept;
reject;
};
};
area 0 {
interface "<VPSと接続しているWireGuardインターフェイス名1の対向IP>" {
type ptp;
neighbors {
<VPSと接続しているWireGuardインターフェイス名1の対向リンクローカルアドレス>;
};
hello 1;
dead 5;
retransmit 5;
priority 0;
cost 10;
bfd yes;
};
interface "<VPSと接続しているWireGuardインターフェイス名2" {
type ptp;
neighbors {
<VPSと接続しているWireGuardインターフェイス名2の対向リンクローカルアドレス>;
};
hello 1;
dead 5;
retransmit 5;
priority 0;
cost 10;
bfd yes;
};
};
}
大体こんな感じ。
6.2.VPS側のBIRDの設定を書く
log syslog all;
router id <VPSのグローバルIP>;
protocol device {
scan time 10;
}
protocol direct {
ipv4;
ipv6;
}
protocol static {
ipv4;
route 0.0.0.0/0 via "<ルーターと接続しているWireGuardインターフェイス名1>";
route 0.0.0.0/0 via "<ルーターと接続しているWireGuardインターフェイス名2>";
}
protocol static {
ipv6;
route ::/0 via "<ルーターと接続しているWireGuardインターフェイス名1>";
route ::/0 via "<ルーターと接続しているWireGuardインターフェイス名2>";
}
protocol kernel {
ipv4 {
import all;
export all;
};
scan time 20;
persist;
learn;
}
protocol kernel {
ipv6 {
import all;
export all;
};
scan time 20;
persist;
learn;
}
protocol bfd {
}
protocol ospf v2 {
tick 10;
rfc1583compat yes;
ipv4 {
import filter {
if net ~ <ルーター側のLANセグメント> then accept;
reject;
};
export filter {
if net = 0.0.0.0/0 then accept;
reject;
};
};
area 0 {
interface "<ルーターと接続しているWireGuardインターフェイス名1>" {
type ptp;
neighbors {
<ルーターと接続しているWireGuardインターフェイス名1の対向IP>;
};
hello 1;
dead 5;
retransmit 5;
priority 0;
cost 10;
bfd yes;
};
interface "<ルーターと接続しているWireGuardインターフェイス名2>" {
type ptp;
neighbors {
<ルーターと接続しているWireGuardインターフェイス名2の対向IP>;
};
hello 1;
dead 5;
retransmit 5;
priority 0;
cost 10;
bfd yes;
};
};
}
protocol ospf v3 {
tick 10;
rfc1583compat yes;
ipv6 {
import filter {
if net ~ <LAN内ULAプリフィックス>/64 then accept;
reject;
};
export filter {
if net = ::/0 then accept;
reject;
};
};
area 0 {
interface "<ルーターと接続しているWireGuardインターフェイス名1>" {
type ptp;
# link lsa suppression no;
neighbors {
<ルーターと接続しているWireGuardインターフェイス名2の対向リンクローカルアドレス>;
};
hello 1;
dead 5;
retransmit 5;
priority 0;
cost 10;
bfd yes;
};
interface "<ルーターと接続しているWireGuardインターフェイス名2>" {
type ptp;
# link lsa suppression no;
neighbors {
<ルーターと接続しているWireGuardインターフェイス名2の対向リンクローカルアドレス>;
};
hello 1;
dead 5;
retransmit 5;
priority 0;
cost 10;
bfd yes;
};
};
}
大体こんな感じです。
7.設定を適用する
VPS -> ルーターの順に以下のコマンドを発行して適用します。
root@Debian13:~# netplan try --timeout 20
root@Debian13:~# systemctl restart bird
root@Debian13:~# reboot
rebootしてるのは99-sysctl.confの値を永続適用するためです。
UFWの設定がキチンと入っていて、ルーターのDNSの発呼がキチンとVPSを経由するようになっていれば、外部への接続元IPがVPSのものに変わっている筈です。
8.BIRD/BFDがキチンと働いているか確認する
BIRD/BFDがキチンと働いている場合は、ルーターとVPSの双方で以下のような表示になろうかと思います。
root@Debian13:~# sudo birdc show protocol
BIRD 3.1.7 ready.
Name Proto Table State Since Info
static1 Static master4 up 14:54:21.367
static2 Static master6 up 14:54:21.367
kernel1 Kernel master4 up 14:54:21.367
kernel2 Kernel master6 up 14:54:21.367
bfd1 BFD --- up 14:54:21.367
ospf1 OSPF master4 up 14:54:21.367 Running
ospf2 OSPF master6 up 14:54:21.367 Running
device1 Device --- up 14:54:21.367
direct1 Direct --- up 14:54:21.367
ospf1/2が両方ともRunningになっていればOK。
逆に動いていない場合はAlone表示になっているはず。
この状態で片方のWireGuardを ip link del しても、直ぐにもう一方のWireGuardにトラフィックが片寄せされて、通信を継続できる筈です(正常に設定出来ていれば)。
9.で、実際のところはVDSL+FTTHで広帯域化出来たんか？
実際に色々試しましたが、 回線状態とスピードテストのプログラムの内容次第で、片寄せされたり両方の回線を使ってロードバランシングされたりするみたい です。
上掲は裏でSpeedometerを使ってWANのトラフィックを監視しながらiNonius Speed Testを走らせた時のもの。
VDSLとFTTH、両方に負荷がキチンとかかっている状態 だったのを確認していて、 VDSLの100Mbps律速を大きく超える速度 が出ています。
ちなみにVDSLはアバウト80Mbps程度ぐらいコンスタントに出ます。
FTTHの方は概して120Mbps程度普通に出て、状況が良ければ250Mbps出るぐらいの回線です。
その他の計測でも概ね同様の傾向でした（fast.comは何かバースト通信でも起きたのかバグり散らかしてる気がするけど）。
- KAGOYA CLOUD VPS自体がコンスタントに230〜285Mbpsぐらいは出るので、概ねVPS相応の限界速度が出ている という認識で良いかと思います
10.デメリットは？
- VPSを経由する分、コンマ何秒以下のレイテンシが問題になるような用途で使おうとすると遅延が気になります
- ULAを使ってNATしているので、その分の遅延により、IPv6でアクセスできていたサイトに、IPv6でアクセスできない場合があります
-
所在地が香港扱いされて使えないサービス(Google系)が発生します(比較的致命傷)
日本のサービスプロバイダのVPSなのに……(´・ω・｀)