トレーサルートの実行

GREトンネルを介して接続されたMagic WANクライアントがある場合、GRE、IPsec、CNIまたはWARPを使用しており、Cloudflare Tunnelの背後にあるエンドポイントに対してtracerouteを実行したい場合、コマンドが有用な情報を返すためには以下の設定を適用する必要があります。

継承されたTTL値

tracerouteクライアントが実行されるマシンでは、トンネルデバイスが内部パケットのTTL値を継承しないことを確認してください。これはLinuxのデフォルトの動作であり、役に立たないtracerouteの結果をもたらす可能性があります：

sudo traceroute -s 10.1.0.100 -I 10.3.0.100

traceroute to 10.3.0.100 (10.3.0.100), 30 hops max, 60 byte packets
 1  * * *
 2  * * *
 3  * * *
 4  * * *
 5  * * *
 6  * * *
 7  * * *
 8  * * *
 9  * * *
10  10.3.0.100 (10.3.0.100)  420.505 ms  420.779 ms  420.776 ms

TTLを明示的に設定すると、はるかに良い結果が得られます：

sudo ip link set cf_gre type gre ttl 64
sudo traceroute -s 10.1.0.100 -I 10.3.0.100

traceroute to 10.3.0.100 (10.3.0.100), 30 hops max, 60 byte packets
 1  10.0.0.11 (10.0.0.11)  58.947 ms  58.933 ms  58.930 ms
 2  173.245.60.175 (173.245.60.175)  61.138 ms  61.316 ms  61.313 ms
 3  172.68.145.21 (172.68.145.21)  367.448 ms  367.532 ms  367.530 ms
 4  mplat-e2e-vm3.c.magic-transit.internal (10.152.0.20)  370.362 ms  370.440 ms  370.522 ms
 5  10.3.0.100 (10.3.0.100)  370.519 ms  370.541 ms  518.152 ms

WARPクライアント

一部のLinuxディストリビューションは、逆パスフィルタリング ↗の非常に厳しい設定をデフォルトにしています。この厳しい設定は、セキュリティ対策として偽のトラフィックをドロップしようとします。この設定でtracerouteを実行すると、意図せずにtracerouteパケットがドロップされる可能性があります。LinuxでWARPを使用している場合、tracerouteを実行する前に、より緩やかなポリシーを設定してください：

sudo sysctl -w net.ipv4.conf.CloudflareWARP.rp_filter=2

net.ipv4.conf.CloudflareWARP.rp_filter = 2

sudo traceroute -s 172.16.0.2 -I 10.3.0.100

traceroute to 10.3.0.100 (10.3.0.100), 30 hops max, 60 byte packets
 1  169.254.21.171 (169.254.21.171)  48.887 ms  48.894 ms  48.620 ms
 2  173.245.60.175 (173.245.60.175)  49.403 ms  49.519 ms  49.603 ms
 3  172.68.65.7 (172.68.65.7)  357.499 ms  357.519 ms  357.520 ms
 4  mplat-e2e-vm3.c.magic-transit.internal (10.152.0.20)  360.024 ms  360.086 ms  360.078 ms
 5  10.3.0.100 (10.3.0.100)  360.283 ms  360.297 ms  360.489 ms