ICMPをフィルタリングしている環境でのmtrやtracerouteの取得方法

1. はじめに

iptableなどのファイアーウォールでAPIコール用の呼び出し(80番/443番）以外はブロックしているようなガチガチに守られている環境で、どのようにmtrやtracerouteを取得するかをBluemix Infrastructure（SoftLayer）を題材にして考えてみたいと思います。

ちなみにここにも書いていますが

• pingはICMP（変更不可）
• mtrのデフォルトはICMP（TCPやUDPに変更可能）
• traceroute(Linux)のデフォルトはUDP（ICMPやTCPに変更可能）
• tracert(Windows)のデフォルトはICMP（変更不可）

であることには常に注意しておきましょう。

2. サーバーでのOutbound フィルタリングされてしまっている例

SoftLayer(Bluemix Infrastructure)の仮想サーバーでは、eth0はPrivate Networkに、eth1はPublic Networkに接続しています。また、yum repositoryやDNSはPrivate Network上に存在しています。
その前提で、下記の/etc/sysconfig/iptablesを見てみて下さい。

• フィルタリングルールのデフォルト値は、OUTPUTチェーンまで含めて全部DROP(禁止）にしています。
• eth0(Private Network)やloopbackインターフェースに関しては特に制限を設けていませんが、eth1(Public Network)については通信制限を行っています。

/etc/sysconfig/iptables

*filter
:INPUT   DROP
:FORWARD DROP
:OUTPUT  DROP

#RELATED, ESTABLISHED
-A INPUT  -m state --state RELATED,ESTABLISHED -j ACCEPT
-A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

#loopback interface
-A INPUT  -i lo   -j ACCEPT
-A OUTPUT -o lo   -j ACCEPT

#eth0 interface
-A INPUT  -i eth0 -j ACCEPT
-A OUTPUT -o eth0 -j ACCEPT

#eth1 interface
-A INPUT  -i eth1 -p tcp -m tcp --dport 20022 --syn -m state --state NEW -j ACCEPT
-A OUTPUT -o eth1 -p tcp -m multiport --dport 80,443 -j ACCEPT

COMMIT

（参考：このiptablesの構成でeth1からSSH(20022番にポートを変更）経由でログインしている場合、-A OUTPUT -o eth1 -p tcp -m tcp --sport 20022 -j ACCEPTみたいなものを追加しておかないと、systemctl restart iptablesだとサービスの再起動の際にstate状態がフラッシュされるためか、既存接続は切断されてしまい再度ログインが必要になる。systemctl reload iptablesであれば、この追加がなくても接続は切られない。）

この場合、そもそもPublic Network（eth1経由）へpingやmtrコマンドを打とうとすると、iptablesにICMPをブロックされてコマンドを発行できません（期待通り）。
特定の通信しか許可しないという構成はセキュリティーの観点では適切ですが、反面問題解析が難しくなります。仮にサーバー自体でここまで仮にガチガチにブロックしていなかったとしても、経路途中のルーターのセキュリティーポリシーによってICMPをブロックされていることもあるでしょう。その場合は、それルーター以降の経路探索ができなくなります。

pingやmtrやtracerouteが取得できない

# ping 161.202.xx.xx
PING 161.202.xx.xx (161.202.xx.xx) 56(84) bytes of data.
ping: sendmsg: Operation not permitted
ping: sendmsg: Operation not permitted
ping: sendmsg: Operation not permitted
ping: sendmsg: Operation not permitted

# mtr -rwb 161.202.xx.xx -c 10
Start: Thu Feb 16 11:22:52 2017
HOST: powerdallas.softlayer.com Loss%   Snt   Last   Avg  Best  Wrst StDev

# traceroute -A 161.202.xx.xx
traceroute to 161.202.xx.xx (161.202.xx.xx), 30 hops max, 60 byte packets
send: Operation not permitted

3. TCPの特定ポートを使ったトレース

心配しないで下さい！このような場合に備えて、mtrやtracerouteは、Firewallを通り抜けられるように、TCPやUDPの特定ポート番号を使って経路探索するオプションを有しています。
今回のケースでは、443番が開いているので、以下のようにすればmtrやtracerouteを取得することができます。今回はインターネットを経由してホスト名解決ができるため、-nオプションの代わりに-bオプションを利用しますが、そもそもprivate NW通信ようにホスト名解決ができない場合には、mtrでもtracerouteでも-nオプションを利用してください。ホスト名解決を試行しなくなります。

TCPポート443を使った経路解析

# mtr -rwb 161.202.xx.xx -c 10 -T -P 443
Start: Thu Feb 16 11:23:21 2017
HOST: powerdallas.softlayer.com                            Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- ???                                                  100.0    10    0.0   0.0   0.0   0.0   0.0
  2.|-- ae104.ppr03.dal10.networklayer.com (169.46.118.168)   0.0%    10    2.6   2.3   1.8   2.8   0.0
  3.|-- ae3.dar02.dal10.networklayer.com (169.46.118.138)     0.0%    10    0.5   1.1   0.5   5.3   1.4
  4.|-- ae11.cbs01.eq01.dal03.networklayer.com (50.97.17.10) 40.0%    10  1004. 1338.   2.8 3008. 1368.1
  5.|-- ae0.cbs01.cs01.lax01.networklayer.com (50.97.17.80)  10.0%    10  7044. 1593.  31.6 7044. 2248.4
  6.|-- ae7.cbs02.cs01.lax01.networklayer.com (50.97.17.61)   0.0%    10   31.2 231.9  31.1 1033. 422.4
  7.|-- ae0.cbs02.eq01.sjc02.networklayer.com (50.97.17.87)   0.0%    10   38.8  38.3  37.6  39.0   0.0
  8.|-- ae24.bbr02.eq01.sjc02.networklayer.com (50.97.17.79)  0.0%    10   36.9  36.7  36.3  37.4   0.0
  9.|-- ae0.bbr01.eq01.tok01.networklayer.com (50.97.18.161)  0.0%    10  133.1 132.5 131.7 133.9   0.5
 10.|-- ae5.dar01.tok02.networklayer.com (50.97.19.133)       0.0%    10  132.3 132.5 132.1 134.2   0.5
 11.|-- po1.fcr01b.tok02.networklayer.com (161.202.118.135)   0.0%    10  134.2 133.8 132.9 134.5   0.0
 12.|-- 4.56.caa1.ip4.static.sl-reverse.com (161.202.xx.xx)    0.0%    10  167.2 170.6 167.2 200.5  10.5

# traceroute 161.202.xx.xx -T -p 443
traceroute to 161.202.86.4 (161.202.86.4), 30 hops max, 60 byte packets
 1  * * *
 2  ae104.ppr03.dal10.networklayer.com (169.46.118.168)  2.452 ms ae104.ppr02.dal10.networklayer.com (169.46.118.166)  2.119 ms ae103.ppr03.dal10.networklayer.com (169.46.118.160)  1.695 ms
 3  ae4.dar02.dal10.networklayer.com (169.46.118.140)  0.546 ms ae5.dar02.dal10.networklayer.com (169.46.118.142)  0.656 ms ae4.dar01.dal10.networklayer.com (169.46.118.132)  0.369 ms
 4  * * ae11.cbs01.eq01.dal03.networklayer.com (50.97.17.10)  2.510 ms
 5  ae0.cbs01.cs01.lax01.networklayer.com (50.97.17.80)  31.077 ms  31.276 ms  31.028 ms
 6  ae7.cbs02.cs01.lax01.networklayer.com (50.97.17.61)  31.002 ms  30.777 ms  31.969 ms
 7  ae0.cbs02.eq01.sjc02.networklayer.com (50.97.17.87)  38.363 ms  38.428 ms *
 8  ae24.bbr02.eq01.sjc02.networklayer.com (50.97.17.79)  37.246 ms  36.958 ms  36.533 ms
 9  ae0.bbr01.eq01.tok01.networklayer.com (50.97.18.161)  131.841 ms  131.926 ms  131.912 ms
10  ae5.dar01.tok02.networklayer.com (50.97.19.133)  132.540 ms  130.223 ms  130.647 ms
11  po1.fcr01a.tok02.networklayer.com (161.202.118.131)  130.636 ms po1.fcr01b.tok02.networklayer.com (161.202.118.135)  130.609 ms  130.948 ms
12  4.56.caa1.ip4.static.sl-reverse.com (161.202.xx.xx)  134.768 ms  130.293 ms  130.709 ms

4. さいごに

Bluemix Infrastructure(SoftLayer)におけるネットワークツールを使った通信問題の判別方法でも記載したとおり、システム設計の段階で、トラブル発生時にどこからどういう手段で問題判別を行うのかを十分に考慮し、予め構築段階から最低限の問題判別に必要なツールを導入しておき、ツールの利用法の確認や正常時のデータの収集を行っておきましょう。