Debianルーターのトラブル
筆者はDebianでIPsec通信環境を構築しインターネットの先にあるクラウドサーバーとの通信を暗号化させています。ルーターではなくDebianルーターを使っているのは、後から必要になったネットワークだったからなのですが、ルーターへの負荷の軽減にもなるかなと考えています。
また、IPSecのトンネルモードの利点を生かし、クラウドサーバーの内側にプライベートアドレスを設けて、そのアドレスを使って通信しています。
クラウドサーバーの内側あてのパケットは、もともとのルーターのルーティングによって、IPSecを受け持つDebianPCに転送されるように設定したのですが、少しおかしな現象が起きました。
4オクテット目が254が従来からあるゲートウェイルーター、252がDebianです。
ネットワークに詳しい人からしてみれば、当たり前なのかもしれないのですが、同じネットワークにあるほかのPCからPingをクラウドサーバーのアドレス(192.168.201.1)に送信すると次のようなメッセージが出ます。
nanbu$ping 192.168.201.1 PING 192.168.201.1 (192.168.201.1) 56(84) bytes of data. From 192.168.1.254: icmp_seq=1 Redirect Host(New nexthop: 192.168.1.252) From 192.168.1.252: icmp_seq=1 Redirect Host(New nexthop: 192.168.1.254) 64 bytes from 192.168.201.1: icmp_seq=1 ttl=63 time=50.0 ms From 192.168.1.254: icmp_seq=2 Redirect Host(New nexthop: 192.168.1.252) From 192.168.1.252: icmp_seq=2 Redirect Host(New nexthop: 192.168.1.254) 64 bytes from 192.168.201.1: icmp_seq=2 ttl=63 time=40.7 ms From 192.168.1.254: icmp_seq=3 Redirect Host(New nexthop: 192.168.1.252) From 192.168.1.252: icmp_seq=3 Redirect Host(New nexthop: 192.168.1.254) 64 bytes from 192.168.201.1: icmp_seq=3 ttl=63 time=36.1 ms
Pingを送信したPCのデフォルトゲートウェイになっている、4オクテット目が254となっているルーターが、ICMPリダイレクトで252のDebianルーターを案内するところまでは問題ないです。しかし、そのあとDebianルーターからもICMPリダイレクトメッセージを送っています。その宛先が254です。これではICMPリダイレクトの意味がありません。
Debianルーター(252)でルーティングを確認してみます。
nanbuDebian$ ip route get 192.168.201.1 192.168.201.1 via 192.168.1.254 dev enp2s0 table 220 src 192.168.1.252 uid 1000 cache nanbuDebian$ip route show table 220 172.16.201.0/24 via 172.16.1.254 dev enp2s0 proto static src 172.16.1.252
特に問題はなさそうです。tableが220番になっているのは、IPsec通信を担うstrongSwanが自動で作成する経路だからです。
このviaの部分から判断してICMPリダイレクトを送信しているのではないかと思われます。
暫定策として、DebianルーターからICMPリダイレクトを送信しないようにします。ICMPリダイレクトを送信しないようにするには次のコマンドを入力します。
これで試してみると、
nanbu$ping 192.168.201.1 PING 192.168.201.1 (192.168.201.1) 56(84) bytes of data. From 192.168.1.254: icmp_seq=1 Redirect Host(New nexthop: 192.168.1.252) From 192.168.1.252: icmp_seq=1 Redirect Host(New nexthop: 192.168.1.254) 64 bytes from 192.168.201.1: icmp_seq=1 ttl=63 time=50.0 ms From 192.168.1.254: icmp_seq=2 Redirect Host(New nexthop: 192.168.1.252) From 192.168.1.252: icmp_seq=2 Redirect Host(New nexthop: 192.168.1.254) 64 bytes from 192.168.201.1: icmp_seq=2 ttl=63 time=40.7 ms From 192.168.1.254: icmp_seq=3 Redirect Host(New nexthop: 192.168.1.252) From 192.168.1.252: icmp_seq=3 Redirect Host(New nexthop: 192.168.1.254) 64 bytes from 192.168.201.1: icmp_seq=3 ttl=63 time=36.1 ms
あれ？ 解決しません。
原因がよくわからないので、いったんファイアウォールで止めてみます。筆者はiptable-persistentを使っているので、/etc/iptables/rules.v4に記述します。そうでない場合はiptablesコマンドに続けて次の記述を入力してください。
... -A OUTPUT -p icmp --icmp-type redirect -j DROP ...
余談ですが、--icmp-typeに指定できる項目を確認するには、「iptables -p icmp -h」とすると出てきます。
これで再びテストをしてみます。
nanbu$ping 192.168.201.1 PING 192.168.201.1 (192.168.201.1) 56(84) bytes of data. From 192.168.1.254: icmp_seq=1 Redirect Host(New nexthop: 192.168.1.252) 64 bytes from 192.168.201.1: icmp_seq=1 ttl=63 time=51.5 ms 64 bytes from 192.168.201.1: icmp_seq=2 ttl=63 time=73.7 ms 64 bytes from 192.168.201.1: icmp_seq=3 ttl=63 time=53.6 ms
一応解決できましたが、いわば対症療法なので気持ちが悪いです。ネットを検索したらDebianではないですが次のような文章がありました。
「net.ipv4.conf.all.send_redirects オプションまたは net.ipv4.conf.interface.send_redirects オプションのいずれかまたは両方を有効に設定すると、ICMP リダイレクトの送信が有効のままになります。」これに従って、設定を入力してみます。
nanbuDebian# sysctl -w net.ipv4.conf.all.send_redirects = 0 nanbuDebian# sysctl -w net.ipv4.conf.<ｲﾝﾀｰﾌｪｰｽ名>.send_redirects = 0
すると、うまくいきました。
最後に、sysctl.confに記述して設定を永続化します。さらにsysctl -pで設定を読み込みエラーとならないか確認します。