IPSEC は複雑な題材です。たくさんの情報がネットワーク上にありますが、 この HOWTO では動作できるようにすること、基本的な原理を 説明することに集中したいと考えています。 すべての例は、上記のリンクにある Racoon をもとにしています。
Note: iptables のたいていの設定では、IPSEC パケットを落としてしまいます! IPSEC を通すには、'iptables -A xxx -p 50 -j ACCEPT' と 'iptables -A xxx -p 51 -j ACCEPT' を使ってください。
IPSEC はセキュリティに優れたインターネットプロトコルです。 ここでの「セキュリティ」には、2 つの意味があります。 暗号化および認証です。わかってない人は、セキュリティすなわち暗号化であると 考えがちですが、それだけでは十分でないことは簡単に示せます。 通信は暗号化していても、通信先が自分の期待している通りかどうかの保証が 一切ないとしたらどうでしょうか?
IPSEC は暗号化には 'Encapsulated Security Payload (ESP)' を、 そしてリモートの通信先の認証には 'Authentication Header (AH)' を用います。 両方を使うようにも設定できますし、片方だけを使うこともできます。
ESP も AH も、security assosiation (SA) に依存しています。 SA は、発信元・送信先・手続きからなります。 例えば認証の SA は次のようになります。
add 10.0.0.11 10.0.0.216 ah 15700 -A hmac-md5 "1234567890123456"; |
ESP SA の例を挙げましょう。
add 10.0.0.11 10.0.0.216 esp 15701 -E 3des-cbc "123456789012123456789012"; |
ここまでのところ、SA が可能な手続きを記述することを見てきましたが、 しかし実は SA は、いつそれが必要になるかに関するポリシーを記述していません。 実際のところ、SPI id のみが異なるほとんど同じ SA を、好きなだけ置くこともできるのです (先ほども述べましたが SPI は Security Parameter Index の意味です)。 実際の暗号化を行うには、ポリシーを記述しなければなりません。 このポリシーには、「可能なら ipsec を使う」とか 「ipsec が使えなければトラフィックを捨てる」とかいった内容を記述できます。
典型的かつ簡単な Security Policy (SP) は次のようなものです。
spdadd 10.0.0.216 10.0.0.11 any -P out ipsec esp/transport//require ah/transport//require; |
別の言い方をすれば、Security Policy は我々が「何を」 必要とするかを指定するのです。Security Association は それを「どのように」必要とするかを記述します。
送り出されるパケットは、SA SPI (「どのように」) でラベル付けされます。 カーネルはこれを使って暗号化と認証を行い、 リモートからはそれに対応する検証と復号化の手続きを調べることができます。
以降に示すのは、ホスト 10.0.0.216 から 10.0.0.11 に対して 暗号化と認証を用いて通信する場合の、非常に簡単な設定です。 ただし最初の版では逆向きは平文ですので、 これは実際に用いてはなりません。
ホスト 10.0.0.216 では:
#!/sbin/setkey -f add 10.0.0.216 10.0.0.11 ah 24500 -A hmac-md5 "1234567890123456"; add 10.0.0.216 10.0.0.11 esp 24501 -E 3des-cbc "123456789012123456789012"; spdadd 10.0.0.216 10.0.0.11 any -P out ipsec esp/transport//require ah/transport//require; |
ホスト 10.0.0.11 では同じ Security Association を用い、 Security Policy は指定しません。
#!/sbin/setkey -f add 10.0.0.216 10.0.0.11 ah 24500 -A hmac-md5 "1234567890123456"; add 10.0.0.216 10.0.0.11 esp 24501 -E 3des-cbc "123456789012123456789012"; |
以上の設定を行えば (これらのファイルは 'setkey' が /sbin にインストールされていれば実行できます)、 10.0.0.126 から行った 'ping 10.0.0.11' は、tcpdump では次のように見えます。
22:37:52 10.0.0.216 > 10.0.0.11: AH(spi=0x00005fb4,seq=0xa): ESP(spi=0x00005fb5,seq=0xa) (DF) 22:37:52 10.0.0.11 > 10.0.0.216: icmp: echo reply |
しかし、ここでいくつかの点に触れておく必要があります。 上記の設定は、多くの IPSEC の例で示されているものですが、 非常に危険なのです。問題は次の点にあります。上記におけるポリシーでは、 10.0.0.216 が 10.0.0.11 に向かうパケットをどう取り扱うかと、 10.0.0.11 がこれらのパケットをどう扱うかは定めていますが、 しかし 10.0.0.11 が認証できない/複号化できないトラフィックを どのように捨てるかを示していないのです!
これでは、誰かが途中でパケットを盗み、 完全に複号化されたパケットで置き換えると、 10.0.0.11 はそれを受け入れてしまいます。 これを避けるには、到着パケットに対する Security Policy が 10.0.0.11 に必要です。次のようにします。
#!/sbin/setkey -f spdadd 10.0.0.216 10.0.0.11 any -P IN ipsec esp/transport//require ah/transport//require; |
さて、設定を完了するには、 もちろん帰りのトラフィックにも同様な暗号化・認証が必要です。 10.0.0.216 における完全な設定は:
#!/sbin/setkey -f flush; spdflush; # AH add 10.0.0.11 10.0.0.216 ah 15700 -A hmac-md5 "1234567890123456"; add 10.0.0.216 10.0.0.11 ah 24500 -A hmac-md5 "1234567890123456"; # ESP add 10.0.0.11 10.0.0.216 esp 15701 -E 3des-cbc "123456789012123456789012"; add 10.0.0.216 10.0.0.11 esp 24501 -E 3des-cbc "123456789012123456789012"; spdadd 10.0.0.216 10.0.0.11 any -P out ipsec esp/transport//require ah/transport//require; spdadd 10.0.0.11 10.0.0.216 any -P in ipsec esp/transport//require ah/transport//require; |
そして 10.0.0.11 では:
#!/sbin/setkey -f flush; spdflush; # AH add 10.0.0.11 10.0.0.216 ah 15700 -A hmac-md5 "1234567890123456"; add 10.0.0.216 10.0.0.11 ah 24500 -A hmac-md5 "1234567890123456"; # ESP add 10.0.0.11 10.0.0.216 esp 15701 -E 3des-cbc "123456789012123456789012"; add 10.0.0.216 10.0.0.11 esp 24501 -E 3des-cbc "123456789012123456789012"; spdadd 10.0.0.11 10.0.0.216 any -P out ipsec esp/transport//require ah/transport//require; spdadd 10.0.0.216 10.0.0.11 any -P in ipsec esp/transport//require ah/transport//require; |
この例では、同一の鍵を両方向のトラフィックに用いています。 しかしこれは、必要条件ではまったくありません。
いま行った設定を確認するには、 setkey -D を実行して Security Association を表示するか、 setkey -DP を実行して設定されたポリシーを表示してください。