投げ銭

★当サイトへの投げ銭(PayPal)★

LINK


(無償、寄付歓迎) logo
世界中で使われるISO標準オフィスソフト(MSオフィス互換)

★LibreOfficeの導入事例★
詳細について

人気の投稿(1ヶ月間)

Ad

Ad

投げ銭

★当サイトへの投げ銭(PayPal)★

2013年10月30日水曜日

【Linux CentOS6.4 minimal 64bit】 IPv6を無効にする方法について

CentOS 6.4 minimal 64bit において、IPv6を無効にする方法について

ネットで調べてみると、さまざまに方法が挙げられていた。

公式見解のようなものを求めていたので、とりあえず、wiki.centos.orgの「 Questions about CentOS 6 」(†1)を試した。
ただし、この方法で発生する問題もあるようだ。(†2)

また、再起動すると、設定は元に戻ってしまう。


□まず、IPv6を無効にする前の状態を確認した
# ip address
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 00:0c:29:fa:dc:5f brd ff:ff:ff:ff:ff:ff
    inet 172.*.*.*/27 brd 172.24.248.31 scope global eth0
    inet6 fe80:xxxx:xxxx:xxxx:xxxx/64 scope link
       valid_lft forever preferred_lft forever


■次のようにコマンドを二つ入力した
# sysctl -w net.ipv6.conf.all.disable_ipv6=1
net.ipv6.conf.all.disable_ipv6 = 1

# sysctl -w net.ipv6.conf.default.disable_ipv6=1
net.ipv6.conf.default.disable_ipv6 = 1


□結果の確認

inet6の表示が消えたことが確認できた。
# ip address
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 00:0c:29:fa:dc:5f brd ff:ff:ff:ff:ff:ff
    inet 172.*.*.*/27 brd 172.24.248.31 scope global eth0
以上



<参考>
(1) Questions about CentOS 6  ( 5. How do I disable IPv6? )
< http://wiki.centos.org/FAQ/CentOS6#head-d47139912868bcb9d754441ecb6a8a10d41781df > 2013年10月30日

(2) 【メモ】CentOS6でIPv6を無効化するには
< http://pocketstudio.jp/log3/2013/04/18/howto_disable_ipv6_on_centos/ > 2013年10月30日

(3) Howto disable IPv6 on Centos 6.4 or Redhat 6.4 RHEL
< http://ithelpblog.com/os/linux/redhat/centos-redhat/howto-disable-ipv6-on-centos-6-4-or-redhat-6-4-rhel/ > 2013年10月30日

2013年10月21日月曜日

【Linux CentOS6.4 64bit版】OpenSWAN(with NETKEY)のパケットの流れを追ってみる【Openswan U2.6.32/K2.6.32-358.18.1.el6.x86_64 (netkey)】

最終更新 2013年10月21日 
 
OpenSWAN(with NETKEY)のパケットの流れを追ってみる

IPsecトンネルを実現するESPパケットの流れや、
そしてIPsecトンネルを出入りするプライベートアドレスを持ったパケットの流れについて、
通過するインターフェイスやチェインを手がかりに考察してみる。


ただし今回は、IPsecトンネルを出入りするパケットはさらにルーティングされない環境を扱っている。
すなわちそれらのパケットはOpenSWANの動作するマシン自身を終端としているものである。

また、今回は、プライベートネットワーク内に仮想的に構築した環境においてテストしているので、
ファイアーウォールについては一切考慮していない。

あくまで勝手な考察なので、間違っているかもしれないので、以下の内容については十分に吟味してください。



▲▽使用環境について▼△

・CentOS 6.4 ( 2.6.32-358.18.1.el6.x86_64 )

 NICは「eth0」の一つだけ装備しグローバルアドレスとして 2.2.2.2 を設定している。
 
 yum install openswan コマンドでOpenSWAN( 21.el6_4 )をインストールした。

 次のコマンドを発行して、OpenSWANの動作に備えた。
# for f in /proc/sys/net/ipv4/conf/*/send_redirects ; do echo 0 > $f ; done
# for f in /proc/sys/net/ipv4/conf/*/accept_redirects ; do echo 0 > $f ; done 
OpenSWANのチェックツールの結果は次の通りだった。
# ipsec verify
Checking your system to see if IPsec got installed and started correctly:
Version check and ipsec on-path                                 [OK]
Linux Openswan U2.6.32/K2.6.32-358.18.1.el6.x86_64 (netkey)
Checking for IPsec support in kernel                            [OK]
 SAref kernel support                                           [N/A]
 NETKEY:  Testing for disabled ICMP send_redirects              [OK]
NETKEY detected, testing for disabled ICMP accept_redirects     [OK]
Checking that pluto is running                                  [OK]
 Pluto listening for IKE on udp 500                             [OK]
 Pluto listening for NAT-T on udp 4500                          [OK]
Checking for 'ip' command                                       [OK]
Checking /bin/sh is not /bin/dash                               [WARNING]
Checking for 'iptables' command                                 [OK]
Opportunistic Encryption Support                                [DISABLED]

 対向側(1.1.1.1)とのIPsecトンネルは設定が済み構築され、すでにトンネルを通ってpingが通じている。

(10.2.0.1)CentOS(2.2.2.2)===========IPsec===========(1.1.1.1)□(10.1.0.1)

 2拠点にはトンネル内で有効なプライベートアドレスがOpenSWANにより設定され、
それぞれ、10.2.0.1、10.1.0.1 である。
 

■ESPパケットの流れを確認する■

○こちら側(ローカルアドレス:10.2.0.1、グローバルアドレス:2.2.2.2)で、ログを取る設定を行った。

INPUT OUTPUT FORWARDのチェインでESPパケットの通過をロギングする。
/sbin/iptables -F

/sbin/iptables -P INPUT ACCEPT
/sbin/iptables -P FORWARD ACCEPT
/sbin/iptables -P OUTPUT ACCEPT

/sbin/iptables -A INPUT  -p esp -j LOG --log-prefix "INPUT"
/sbin/iptables -A OUTPUT -p esp -j LOG --log-prefix "OUTPUT"
/sbin/iptables -A FORWARD -p esp -j LOG --log-prefix "FORWARD"
 
○対向側(ローカルアドレス 10.1.0.1)からこちら側(ローカルアドレス 10.2.0.1)へpingを打ちつづけた。
# ping 10.2.0.1
10.2.0.1から受信: シーケンス番号=0 ttl=63 時間=1.059ミリ秒
10.2.0.1から受信: シーケンス番号=1 ttl=63 時間=1.225ミリ秒
10.2.0.1から受信: シーケンス番号=2 ttl=63 時間=1.168ミリ秒
10.2.0.1から受信: シーケンス番号=3 ttl=63 時間=1.334ミリ秒
10.2.0.1から受信: シーケンス番号=4 ttl=63 時間=1.216ミリ秒
10.2.0.1から受信: シーケンス番号=5 ttl=63 時間=1.159ミリ秒

○こちら側(ローカルアドレス 10.2.0.1)において、ログを確認した。
# tail /var/log/messages

Oct  2 00:53:38 localhost kernel:
INPUT
IN=eth0 OUT=
MAC=xx:xx:xx:xx:xx:xx: yy:yy:yy:yy:yy:yy: 08:00
SRC=1.1.1.1 DST=2.2.2.2 LEN=152 TOS=0x00 PREC=0x00 TTL=253 ID=21127
PROTO=ESP SPI=0x11111111

Oct  2 00:53:38 localhost kernel:
OUTPUT
IN= OUT=eth0
SRC=2.2.2.2 DST=1.1.1.1 LEN=152 TOS=0x00 PREC=0x00 TTL=64 ID=45901
PROTO=ESP SPI=0x22222222

Oct  2 00:53:39 localhost kernel:
INPUT
IN=eth0 OUT=
MAC=xx:xx:xx:xx:xx:xx: yy:yy:yy:yy:yy:yy: 08:00
SRC=1.1.1.1 DST=2.2.2.2 LEN=152 TOS=0x00 PREC=0x00 TTL=253 ID=21130
PROTO=ESP SPI=0x11111111

Oct  2 00:53:39 localhost kernel:
OUTPUT
IN= OUT=eth0
SRC=2.2.2.2 DST=1.1.1.1 LEN=152 TOS=0x00 PREC=0x00 TTL=64 ID=45902
PROTO=ESP SPI=0x22222222

Oct  2 00:53:40 localhost kernel:
INPUT
IN=eth0 OUT=
MAC=xx:xx:xx:xx:xx:xx: yy:yy:yy:yy:yy:yy: 08:00
SRC=1.1.1.1 DST=2.2.2.2 LEN=152 TOS=0x00 PREC=0x00 TTL=253 ID=21133
PROTO=ESP SPI=0x11111111


Oct  2 00:53:40 localhost kernel:
OUTPUT
IN= OUT=eth0
SRC=2.2.2.2 DST=1.1.1.1 LEN=152 TOS=0x00 PREC=0x00 TTL=64 ID=45903
PROTO=ESP SPI=0x22222222

以上の結果から、使用の環境においてESPパケットは、
INPUTとOUTPUTチェインに現れるが、FORWARDチェインには現れないことがわかる。

そして次のように考えることができると思った。

外部からのESPパケットは、グローバルアドレスを持つ「eth0」からINPUTチェインを通過して、
IPsec関係のプロセスに到達し処理される。

逆に、内部のIPsec関係のプロセスによって作成されたESPパケットは、
OUTPUTチェインを通過して、グローバルアドレスを持つ「eth0」からネットワーク上に出て行く。


つづいて、ESPカプセルに出入りするICMPパケットの流れを追う。



■IPsecトンネル内を通過するICMPパケットの流れを確認する■

○こちら側(ローカルアドレス 10.2.0.1)で、ログを取る設定を行った。

INPUT OUTPUT FORWARDのチェインでICMPパケットの通過をロギングする。
/sbin/iptables -F

/sbin/iptables -P INPUT ACCEPT
/sbin/iptables -P FORWARD ACCEPT
/sbin/iptables -P OUTPUT ACCEPT

/sbin/iptables -A INPUT  -p icmp -j LOG --log-prefix "INPUT"
/sbin/iptables -A OUTPUT -p icmp -j LOG --log-prefix "OUTPUT"
/sbin/iptables -A FORWARD -p icmp -j LOG --log-prefix "FORWARD"

○対向側(ローカルアドレス 10.1.0.1)からこちら側(ローカルアドレス 10.2.0.1)へpingを打ちつづけた。
# ping 10.2.0.1
10.2.0.1から受信: シーケンス番号=0 ttl=63 時間=2.815ミリ秒
10.2.0.1から受信: シーケンス番号=1 ttl=63 時間=1.198ミリ秒
10.2.0.1から受信: シーケンス番号=2 ttl=63 時間=1.374ミリ秒
10.2.0.1から受信: シーケンス番号=3 ttl=63 時間=1.206ミリ秒
10.2.0.1から受信: シーケンス番号=4 ttl=63 時間=1.190ミリ秒
10.2.0.1から受信: シーケンス番号=5 ttl=63 時間=1.326ミリ秒

○こちら側(ローカルアドレス 10.2.0.1)において、ログを確認した。
# tail /var/log/messages

Oct 21 04:09:29 localhost kernel:
INPUT
IN=eth0 OUT=
MAC=xx:xx:xx:xx:xx:xx: yy:yy:yy:yy:yy:yy: 08:00
SRC=10.1.0.1 DST=10.2.0.1
LEN=92 TOS=0x00 PREC=0x00 TTL=255 ID=41
PROTO=ICMP TYPE=8 CODE=0 ID=64457 SEQ=90

Oct 21 04:09:29 localhost kernel:
OUTPUT
IN= OUT=eth0
SRC=10.2.0.1 DST=10.1.0.1
LEN=92 TOS=0x00 PREC=0x00 TTL=64 ID=45501
PROTO=ICMP TYPE=0 CODE=0 ID=64457 SEQ=90

Oct 21 04:09:30 localhost kernel:
INPUT
IN=eth0 OUT=
MAC=xx:xx:xx:xx:xx:xx: yy:yy:yy:yy:yy:yy: 08:00
SRC=10.1.0.1 DST=10.2.0.1
LEN=92 TOS=0x00 PREC=0x00 TTL=255 ID=44
PROTO=ICMP TYPE=8 CODE=0 ID=64458 SEQ=91

Oct 21 04:09:30 localhost kernel:
OUTPUT
IN= OUT=eth0
SRC=10.2.0.1 DST=10.1.0.1
LEN=92 TOS=0x00 PREC=0x00 TTL=64 ID=45502
PROTO=ICMP TYPE=0 CODE=0 ID=64458 SEQ=91

トンネルに出入りするicmpパケットは、
使用の環境においてINPUTとOUTPUTチェインに現れるが、
FORWARDチェインには現れないことがわかる。



■以上のことから、次のように考えた■

あくまでも推測であり、自分なりの理解です。
実際の動きとは異なると思われるので、ご注意ください。

以上のテストから次の流れが見える。
外部から来たESPカプセルは、INPUTチェインを通過し、IPsec関係プロセスにより処理され、
プライベートアドレス(10.2.0.1)宛てのICMPリクエストパケット(TYPE=8)がその中から取り出される。
そしてこの取り出されたパケットは、おかしいことに「eth0」からINPUTチェインを通過し、
ICMPリクエストパケットを処理するプロセスに到達する。


これについて、さらに次のように考えた。

IPsec関係プロセスによってESPカプセルから取り出されたこのICMPリクエストパケット(TYPE=8)は、
一切、OUTPUTチェインやFORWARDチェインを通過していない。
にわかに、あたかも「eth0」の外からやってかのように現れ、INPUTチェインを通過し、
ICMPリクエストパケットを処理するプロセスに到達しているように見える。
ここに、NETKEYを用いたIPsecトンネル出入り口の秘密があるようだ。

一方、内部のICMPパケットを処理するプロセスによって作成されたICMPリプライパケット(TYPE=0)は、
プライベートアドレス(10.1.0.1)宛てである。
これはOUTPUTチェインを通過して、「eth0」からネットワーク上に出て行くよう方向づけられている。

routeコマンドでも、対向ネットワーク宛のプライベートパケットは、eth0へのルーティングテーブルを表示していた。(↓)

10.1.0.0        *               255.255.0.0     U     0      0        0 eth0

しかし、eth0へ向かうもののネットワーク上に出ずに、直後にIPsecパケットにカプセル化されていると思われる。

さきほどは、カプセルを解かれたパケットが入力されるときの秘密について考えた。
IPsec関係プロセスによってカプセルを解かれたICMPパケットが、
あたかも「eth0」の外にジャンプしたかのように現れマシンに入力されるのだった。
逆に、カプセル化されるパケットもまた、「eth0」へ行き先が方向づけられた後で、
IPsec関係プロセスに捕捉されカプセル化されるのではないかと思う。

カプセリング処理されて然るべきパケット(OpenSWANの対向ネットワーク設定に拠ると思われる。)については、
「eth0」に出力されると見せかけて実際はネットワーク上へは流れ出ずに、
IPsec関係のプロセスによって途中で捕捉され、カプセル化処理を受けるのだと思う。
ここで生成されたESPパケットが、OUTPUTチェインを経てグローバルアドレス(2.2.2.2)を持つ「eth0」からネットワーク上に出て行くのだと思う。

2013年10月6日日曜日

【Linux CentOS6.4 64bit版 minimal】 OpenSWAN( with NETKEY )同士で、IPsecトンネルの構築を行った【openswan.x86_64 0:2.6.32-21.el6_4】

最終更新 2013年11月1日

CentOS 6.4 64bit版 minimalに、OpenSWANをインストールしたものを2台用意し、
2台を結ぶIPsecトンネルの構築と疎通テストを行った。
OpenSWANのインストール方法、トンネル構築に必要な基本的な設定についてのメモ。
ファイアウォールの導入などセキュリティーについては考慮していない。
そのため、プライベートネットワークを利用して動作テストを行っている。

この動作テストには2台のマシンが必要である。
以下、2台のマシンをそれぞれ準備していることに留意してください。

接続テストでは、トンネル構築のベースとして172.16.*.*(クラスB)の安全なプライベートネットワークを使用した。
2台のマシンはそれぞれeth0を持っていて、異なるネットワークに所属するように設定した。
下記のように、ルーターを通じて相互にパケットを転送できる状態である。

マシンA[eth0 172.24.250.40]--------【ルーター】-------[172.24.248.4 eth0]マシンB


以上のベースネットワーク環境において、テスト用IPsecトンネルを設定した。(下図)
それぞれのマシンの背景には、IPsecトンネルを通じることで相互に接続可能なネットワークを想定している。
このネットワークは、マシンA側は 10.10.0.0/16、マシンB側は 10.11.0.0/16 である。
ただし今回は、それぞれのネットワークにはその各マシンしか存在していない環境を扱った。
マシンAは 10.10.0.1、マシンBは 10.11.0.1 を割り当てた。
(これらは、OpenSWANの設定ファイルに記述することで設定される。)

---マシンA(10.10.0.1/16)========IPsecトンネル=======(10.11.0.1/16)マシンB---

これは、IPsecトンネルを通じて相互に通信が可能だが、それぞれのマシンが終端となる環境である。
NICは、それぞれ eth0 しか存在していない。



■ CentOS 6のインストールと設定、OpenSWANのインストールを行った

☆代わりにLibreswanをインストールしたい場合は、こちらを参照



1、CentOS 6.4 64bit版 を、minimalでインストールした。

2、次のリンク先にある「1、ネットワークインターフェイスの有効化を行った」を参考にして、
eth0インターフェイスを有効にした。
http://akira-arets.blogspot.jp/2012/02/minimal-centos62-initialize.html

3、yum update コマンドでシステムの更新を行った。

 更新後、カーネルのバージョンは次のようになった。
# uname -a
Linux test-3.localdomain 2.6.32-358.el6.x86_64 #1 SMP Fri Feb 22 00:31:26 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

4、OpenSWANのインストールを行った。
# yum install openswan

Installed:
  openswan.x86_64 0:2.6.32-21.el6_4

Dependency Installed:
  perl.x86_64 4:5.10.1-131.el6_4       perl-Module-Pluggable.x86_64 1:3.90-131.el6_4  perl-Pod-Escapes.x86_64 1:1.04-131.el6_4  perl-Pod-Simple.x86_64 1:3.13-131.el6_4
  perl-libs.x86_64 4:5.10.1-131.el6_4  perl-version.x86_64 3:0.77-131.el6_4

Complete!


■ OpenSWANの基本的な設定を行った

1、まず、IPsecサービスを起動しておく。
# service ipsec start
ipsec_setup: Starting Openswan IPsec U2.6.32/K2.6.32-358.el6.x86_64...

2、IPsecが動作するために必要な前提条件をチェックした。

 後で、FAILEDになっている項目( 1~4 )について、直下に表示される対処法を参考にして、対策を行う。
# ipsec verify
Checking your system to see if IPsec got installed and started correctly:
Version check and ipsec on-path                                 [OK]
Linux Openswan U2.6.32/K2.6.32-358.el6.x86_64 (netkey)
Checking for IPsec support in kernel                            [OK]
 SAref kernel support                                           [N/A]
 (1) NETKEY:  Testing for disabled ICMP send_redirects              [FAILED]

  Please disable /proc/sys/net/ipv4/conf/*/send_redirects
  or NETKEY will cause the sending of bogus ICMP redirects!

(2) NETKEY detected, testing for disabled ICMP accept_redirects     [FAILED] 
  Please disable /proc/sys/net/ipv4/conf/*/accept_redirects
  or NETKEY will accept bogus ICMP redirects!

(3) Testing against enforced SElinux mode                           [FAILED]

  SElinux is running in 'enforced' mode.
  If you encounter network related SElinux errors, especially when using KLIPS,
  try disabling SElinux using:

  echo "0" > /selinux/enforce (or edit /etc/sysconfig/selinux)


Checking that pluto is running                                  [OK]
 (4) Pluto listening for IKE on udp 500                             [FAILED]
  Cannot execute command "lsof -i UDP:500": そのようなファイルやディレクトリはありません
 (4) Pluto listening for NAT-T on udp 4500                          [FAILED]
  Cannot execute command "lsof -i UDP:4500": そのようなファイルやディレクトリはありません
Checking for 'ip' command                                       [OK]
Checking /bin/sh is not /bin/dash                               [WARNING]
Checking for 'iptables' command                                 [OK]
Opportunistic Encryption Support                                [DISABLED]

3、上記のチェックで判明した満たすべき条件に対して、対処を行った。

(1) ICMP redirect を送信しないように設定しなければいけない。
(2) ICMP redirect を受信しないように設定しなければならない。

現状を次のコマンドでチェックした。
値が 1 になっているものは、有効になっているので、無効にしなければいけない。
# for i in  /proc/sys/net/ipv4/conf/*/send_redirects ; do ls $i ; cat $i ; done

/proc/sys/net/ipv4/conf/all/send_redirects
1
/proc/sys/net/ipv4/conf/default/send_redirects
1
/proc/sys/net/ipv4/conf/eth0/send_redirects
1
/proc/sys/net/ipv4/conf/lo/send_redirects
1

# for i in  /proc/sys/net/ipv4/conf/*/accept_redirects ; do ls $i ; cat $i ; done

/proc/sys/net/ipv4/conf/all/accept_redirects
1
/proc/sys/net/ipv4/conf/default/accept_redirects
1
/proc/sys/net/ipv4/conf/eth0/accept_redirects
1
/proc/sys/net/ipv4/conf/lo/accept_redirects
1


 無効設定にするために、カーネルシステムパラメータを設定した。
 必要なパラメーターが存在しなかったので、パラメータとその値を次のように追加した。
# vi /etc/sysctl.conf
(略)
# IPsec
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.default.accept_redirects = 0
net.ipv4.conf.eth0.accept_redirects = 0
net.ipv4.conf.lo.accept_redirects = 0

net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.default.send_redirects = 0
net.ipv4.conf.eth0.send_redirects = 0
net.ipv4.conf.lo.send_redirects = 0
(略)

 編集の後に、次のようにコマンドを実行し、設定を反映させた。

# sysctl -p

net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.default.accept_redirects = 0
net.ipv4.conf.eth0.accept_redirects = 0
net.ipv4.conf.lo.accept_redirects = 0
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.default.send_redirects = 0
net.ipv4.conf.eth0.send_redirects = 0
net.ipv4.conf.lo.send_redirects = 0

net.ipv4.ip_forward = 0
net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.default.accept_source_route = 0
kernel.sysrq = 0
kernel.core_uses_pid = 1
net.ipv4.tcp_syncookies = 1
error: "net.bridge.bridge-nf-call-ip6tables" is an unknown key
error: "net.bridge.bridge-nf-call-iptables" is an unknown key
error: "net.bridge.bridge-nf-call-arptables" is an unknown key
kernel.msgmnb = 65536
kernel.msgmax = 65536
kernel.shmmax = 68719476736
kernel.shmall = 4294967296

(3) SElinux を無効にしなければならない。

次のページの方法で、SElinuxを無効化した。 (再起動が必要)
http://akira-arets.blogspot.jp/2012/03/centos6-disabled-selinux.html


(4) lsof コマンドが必要である。
# yum install lsof
Installed:
  lsof.x86_64 0:4.82-4.el6

Complete!

4、IPsecサービスを再起動後に、前提条件が満たされたか再度チェックした

○IPsecサービスの起動
# service ipsec start
ipsec_setup: Starting Openswan IPsec U2.6.32/K2.6.32-358.18.1.el6.x86_64...
○前提条件のチェック
# ipsec verify
Checking your system to see if IPsec got installed and started correctly:
Version check and ipsec on-path                                 [OK]
Linux Openswan U2.6.32/K2.6.32-358.18.1.el6.x86_64 (netkey)
Checking for IPsec support in kernel                            [OK]
 SAref kernel support                                           [N/A]
 NETKEY:  Testing for disabled ICMP send_redirects              [OK]
NETKEY detected, testing for disabled ICMP accept_redirects     [OK]

Checking that pluto is running                                  [OK]
 Pluto listening for IKE on udp 500                             [OK]
 Pluto listening for NAT-T on udp 4500                          [OK]

Checking for 'ip' command                                       [OK]
Checking /bin/sh is not /bin/dash                               [WARNING]
Checking for 'iptables' command                                 [OK]
Opportunistic Encryption Support                                [DISABLED]

以上でOpenSWANのインストールと基本設定は完了した。


5、IPsecトンネルの動作テストを行うために、対向側用にも同じような環境を設定した。

 すでに述べたように、インストールと基本設定を行った。


これで、テスト環境として、マシンが二つ揃った。
pingを打って、対向側が応答することを確認しておく。

また、簡単のために双方のマシンにおいて、iptablesを無効にしておく
言うまでもなく、安全なプライベート環境で実験しなければならない

以下では、IPsecトンネルのテスト環境を設定し動作させる。



■テスト環境として、IPsecトンネルの設定と疎通テストを行った


1、設定ファイルの作成や編集

下記、各項目について設定ファイルを作成、あるいは編集を行った。
テスト用の両マシンで設定を行う。
両マシンで、まったく同じ設定ファイルで良い。


○トンネル構築用設定ファイル

conn test-11and10 の行以外は、すべて頭に半角スペースを置くこと!!
さもなければ、文法エラーとなってしまう。

IPsecトンネルの端点は、leftとrightという言葉で区別しているが、区別以上の意味はないようだ。

IPsecトンネルを経由して相互に通信するときのマシンAと、マシンB自身のアドレスは、
それぞれ下記のように rightsourceip、leftsourceip に設定を行う。

ifconfig コマンドの結果からは確認できなかったが、このアドレスは、
ip address コマンドが、マシンBにおいて「inet 10.11.0.1/32 scope global eth0」と示すように、
eth0に設定されているようだ。ただし、サブネットマスクが「/32」になっている。

# vi /etc/ipsec.d/test-11and10.conf
conn test-11and10

 type=tunnel
 authby=secret
 phase2=esp

 ike=aes256-sha1;modp1024
 phase2alg=aes256-sha1

 keyexchange=ike
 pfs=no
 ikelifetime=28800s
 keylife=28800s
 compress=no

## MACHINE B
 left=172.24.248.4

 leftsubnet=10.11.0.0/16
 leftsourceip=10.11.0.1

## MACHINE A
 right=172.24.250.40

 rightsubnet=10.10.0.0/16
 rightsourceip=10.10.0.1

 dpddelay=5
 dpdtimeout=20
 dpdaction=restart

 auto=start

○事前共有鍵設定ファイル

次の設定ファイルを作成して、鍵交換時に使用される事前共有鍵を設定した。
もちろん、これはテスト用の鍵である。
# vi /etc/ipsec.d/test-11and10.secrets
172.24.248.4 172.24.250.40: PSK "testtesttest"

○設定用メインファイル

次の設定ファイルを編集して、上で作成した設定ファイルをロードするように設定した。
# vi /etc/ipsec.conf
※最後の行のコメントアウトを解除した。その他は編集しない。
include /etc/ipsec.d/*.conf


2、両端のマシンでIPsecサービスを再起動し、トンネルの疎通テストを行った。

IPsecサービスの再起動

例として、マシンBの様子を挙げた。

# service ipsec stop
ipsec_setup: Stopping Openswan IPsec...
# service ipsec start
ipsec_setup: Starting Openswan IPsec U2.6.32/K2.6.32-358.23.2.el6.x86_64...
ipsec_setup: multiple ip addresses, using  172.24.248.4 on eth0
ipsec_setup: /usr/libexec/ipsec/addconn Non-fips mode set in /proc/sys/crypto/fips_enabled

疎通テスト

<マシンBにおいて>
# tracepath 10.10.0.1
 1?: [LOCALHOST]     pmtu 1456
 1:  10.11.0.1 (10.11.0.1)                                  0.031ms pmtu 1438
 1:  10.10.0.1 (10.10.0.1)                                  2.220ms reached
 1:  10.10.0.1 (10.10.0.1)                                  1.525ms reached
     Resume: pmtu 1438 hops 1 back 64

# ping 10.10.0.1
PING 10.10.0.1 (10.10.0.1) 56(84) bytes of data.
64 bytes from 10.10.0.1: icmp_seq=1 ttl=64 time=0.771 ms
64 bytes from 10.10.0.1: icmp_seq=2 ttl=64 time=0.979 ms
64 bytes from 10.10.0.1: icmp_seq=3 ttl=64 time=0.978 ms
64 bytes from 10.10.0.1: icmp_seq=4 ttl=64 time=0.729 ms
64 bytes from 10.10.0.1: icmp_seq=5 ttl=64 time=1.00 ms
64 bytes from 10.10.0.1: icmp_seq=6 ttl=64 time=0.974 ms
64 bytes from 10.10.0.1: icmp_seq=7 ttl=64 time=0.766 ms
^C
--- 10.10.0.1 ping statistics ---
7 packets transmitted, 7 received, 0% packet loss, time 6197ms
rtt min/avg/max/mdev = 0.729/0.886/1.007/0.116 ms

<マシンAにおいて>
# tracepath 10.11.0.1
 1?: [LOCALHOST]     pmtu 1456
 1:  10.10.0.1 (10.10.0.1)                                  0.037ms pmtu 1438
 1:  10.11.0.1 (10.11.0.1)                                  1.651ms reached
 1:  10.11.0.1 (10.11.0.1)                                  1.409ms reached
     Resume: pmtu 1438 hops 1 back 64

# ping 10.11.0.1
PING 10.11.0.1 (10.11.0.1) 56(84) bytes of data.
64 bytes from 10.11.0.1: icmp_seq=1 ttl=64 time=0.754 ms
64 bytes from 10.11.0.1: icmp_seq=2 ttl=64 time=0.725 ms
64 bytes from 10.11.0.1: icmp_seq=3 ttl=64 time=0.891 ms
64 bytes from 10.11.0.1: icmp_seq=4 ttl=64 time=0.727 ms
64 bytes from 10.11.0.1: icmp_seq=5 ttl=64 time=0.794 ms
64 bytes from 10.11.0.1: icmp_seq=6 ttl=64 time=0.816 ms
64 bytes from 10.11.0.1: icmp_seq=7 ttl=64 time=0.960 ms
^C
--- 10.11.0.1 ping statistics ---
7 packets transmitted, 7 received, 0% packet loss, time 6237ms
rtt min/avg/max/mdev = 0.725/0.809/0.960/0.087 ms

routeの確認

次のように、必要な経路が自動的に設定されていた。

トンネルを通る必要のあるパケットは、eth0に流されるように方向付けられることがわかった。
パケットの流れについての詳細は、次のページを参考にしてください。
http://akira-arets.blogspot.jp/2013/10/openswan-packet-flow.html

例として、マシンBの様子を挙げた。
# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
172.24.248.0    *               255.255.255.224 U     0      0        0 eth0
10.10.0.0       *               255.255.0.0     U     0      0        0 eth0
link-local      *               255.255.0.0     U     1002   0        0 eth0
default         172.24.248.1    0.0.0.0         UG    0      0        0 eth0
また、ipsecサービスを終了させると、自動的に経路が消去された。


以上です。



<参考>
・ipsec.conf(5) - Linux man page
< http://linux.die.net/man/5/ipsec.conf > 2013年10月6日

・Set Up IPsec Under Linux
< http://codeidol.com/sql/network-security-hack/Secure-Tunnels/Set-Up-IPsec-Under-Linux/ > 2013年10月6日

・Redhat Enterprise Linux 6 IPSec configuration example
< http://blog.erben.sk/2012/05/10/redhat-enterprise-linux-6-ipsec-configuration-example/ > 2013年10月6日

・Openswan – Use The KLIPS stack
< http://linuxplayer.org/2011/02/openswan-use-the-klips-stack > 2013年10月6日

・IPsec 相互接続の手引き
< http://www.rtpro.yamaha.co.jp/RT/docs/ipsec/interop.html > 2013年10月6日

・Openswanを使って拠点間VPNを構築する
< http://lab.space-i.com/?p=1501 > 2013年10月6日

・YAMAHA RTX1100 と OpenSwan で IPSec VPN 接続
< http://www.shakke.com/network/vpn/yamaha-rtx1100-%E3%81%A8-openswan-%E3%81%A7-ipsec-vpn-%E6%8E%A5%E7%B6%9A/ > 2013年10月6日

・How to set up Host-to-Host VPN using Openswan/IPSec on CentOS
< http://mute.nu/2011/how-to-set-up-host-to-host-vpn-using-openswan-ipsec-on-centos/ > 2013年10月6日

・[Openswan Users] [FAILED] messages
< https://lists.openswan.org/pipermail/users/2006-April/009133.html > 2013年10月6日

・kernel/システムパラメタ
< http://linux.mini13i.com/?kernel%2F%A5%B7%A5%B9%A5%C6%A5%E0%A5%D1%A5%E9%A5%E1%A5%BF > 2013年10月6日

投げ銭

★当サイトへの投げ銭(PayPal)★

Ad

Ad