なんだか日曜ですが、ブログ書いてます。にゃんぱすー。
BGMは、さっきまでエヴァ破でしたが、やっぱまったり系が良くて、おねがいシリーズを観ながら作業してマス。
複数のOpenSwanサーバによる、IPSecサーバの負荷分散
今回、とある案件により、大規模IPSecセンタールータを構築する案件がありました。
この事前検証の結果を公開する形となります。
備考録的なエントリとなる為、ログや確認コマンド少なめデス。（そのあたりはぐぐってください。。。）
OverView
拠点ルータ（今回はYAMAHA RTX810）は、ipsecの対向アドレスにFQDNを使う事が可能です。
今回、その特性を利用し、Route53でDNSラウンドロビンを構成し、複数台のIPSecサーバへ負荷を分散する実装です。
また、IPSecサーバでSNATを構成する事により、戻りルート（RouteTable）の問題を解決し、同時にSrc/Dst Checkの無効化を不要にします。
技術的なキモ
IPSec相互接続を構成した上で、上記のような設定を行います。
これにより、どのVPNサーバに繋がってもPhase1を構成する事が可能です。また、この設定と同等の設定が出来れば、他社ルータでも実装が可能かもしれません。
構築ドキュメント
事前に、Aレコードの設定は終わっているものとします。
以下、AmazonLinux(HVM) 64bitインストール直後と仮定します。環境により適宜読み替えてください。
% sudo yum install --enablerepo=epel openswan -y % sudo iptables -t nat -A POSTROUTING -d 172.16.0.0/16 -o eth0 -j MASQUERADE % sudo service iptables save % sudo service iptables restart % sudo chkconfig iptables on % sudo sed -i "s/net.ipv4.ip_forward = 0/net.ipv4.ip_forward = 1/g" /etc/sysctl.conf % cat /dev/null # Configure for OpenSwan. net.ipv4.conf.all.send_redirects = 0 net.ipv4.conf.all.accept_redirects = 0 net.ipv4.conf.default.send_redirects = 0 net.ipv4.conf.default.accept_redirects = 0 net.ipv4.conf.lo.send_redirects = 0 net.ipv4.conf.lo.accept_redirects = 0 net.ipv4.conf.eth0.send_redirects = 0 net.ipv4.conf.eth0.accept_redirects = 0 _EOF_ % sudo sysctl -p % echo "FORWARD_IPV4=yes" | tee -a /etc/sysconfig/network > /dev/null % service network restart % sudo cp -prv /etc/ipsec.conf /etc/ipsec.conf.orig % sudo cp -prv /etc/ipsec.secrets /etc/ipsec.secrets.orig % sudo sed -i "s/virtual_private=/virtual_private=%v4:10.0.0.0/8,%v4:172.16.0.0/12,%v4:192.168.0.0/16,%v4:!172.16.1.0/24/g" /etc/ipsec.conf ※172.16.1.0/24 - VPNサーバの存在するSubnet % sudo sed -i "s/nat_traversal=.*/nat_traversal=no/g" /etc/ipsec.conf % sudo sed -i "s/^#include/include/g" /etc/ipsec.conf % echo ': PSK "himitsu"' | sudo tee /etc/ipsec.d/ipsec.secrets > /dev/null ※ ルータに設定する事前共有鍵 % cat /dev/null conn site-_SITENAME_ type=tunnel authby=secret auto=add ### Phase1 pfs=no aggrmode=no keyexchange=ike ike=aes128-sha1;modp1024 dpddelay = 5 dpdtimeout = 20 dpdaction = restart left=_PIPADDR_ leftid=_PIPADDR_ leftsubnet=172.16.0.0/16 leftnexthop=%defaultroute right=_REMOTE_GLOBAL_IP_ rightid=_REMOTE_LOCAL_IP_ rightsubnet=_REMOTE_LOCAL_SUBNET_ rightnexthop=%defaultroute ### Phase2 phase2=esp compress=no phase2alg=aes128-sha1;modp1024 _EOF_ sudo chkconfig ipsec on sudo shutdown -r now
ここまで設定する事で、一通りの設定は終わりです。
その他VPCの設定として、インスタンスへ以下のSecurityGroupを設定します。
o 500/udp(isakmp) – 0.0.0.0/0
o CustomProtocol 50(ESP) – 0.0.0.0/0
拠点の追加
以下のコマンドを実行します。
PIPADDR=`curl -s 169.254.169.254/latest/meta-data/local-ipv4`
SITENAME="mikalab"
RGIPADDR="xx.xx.xx.xx"
RPIPADDR="192.168.0.1"
RSUBNET="192.168.0.0/24"
RSUBNET=echo ${RSUBNET} | sed -e "s///\\\//g"
sudo cp -prv /etc/ipsec.d/site_example.conf.example /etc/ipsec.d/site-${SITENAME}.conf
sudo sed -i "s/_PIPADDR_/$PIPADDR/g" /etc/ipsec.d/site-${SITENAME}.conf
sudo sed -i "s/site-_SITENAME_/${SITENAME}/g" /etc/ipsec.d/site-${SITENAME}.conf
sudo sed -i "s/_REMOTE_GLOBAL_IP_/${RGIPADDR}/g" /etc/ipsec.d/site-${SITENAME}.conf
sudo sed -i "s/_REMOTE_LOCAL_IP_/${RPIPADDR}/g" /etc/ipsec.d/site-${SITENAME}.conf
sudo sed -i "s/_REMOTE_LOCAL_SUBNET_/${RSUBNET}/g" /etc/ipsec.d/site-${SITENAME}.conf
RTXの設定
上記のConfigに対応する設定は、以下の通りです。
GlobalIPAddressはipcpで取得する事を前提に、ipsec部分のみ抜き出します。
tunnel select 1 ipsec tunnel 1 ipsec sa policy 1 1 esp aes-cbc sha-hmac ipsec ike duration ipsec-sa 1 28800 100000 ipsec ike duration isakmp-sa 1 28800 100000 ipsec ike encryption 1 aes-cbc ipsec ike esp-encapsulation 1 off ipsec ike group 1 modp1024 ipsec ike hash 1 sha ipsec ike keepalive log 1 off ipsec ike keepalive use 1 on dpd 5 4 ipsec ike local address 1 192.168.0.1 ipsec ike local id 1 192.168.0.0/24 ipsec ike log 1 key-info message-info ipsec ike pre-shared-key 1 text himitsu ipsec ike remote address 1 vpn.mikalab.example ipsec ike remote id 1 172.16.0.0/16 ipsec auto refresh 1 on ip tunnel tcp mss limit auto tunnel enable 1
厳密にはAES128ではなくAES256の方が良い気もするのですが、取り急ぎ相互接続性を優先しました。
実際の挙動
DPDによりSAのダウンが検出されたか、鍵の寿命が尽きた時、SAが再確立されます。
この際、RTXはPhase1の鍵交換を行う直前に名前解決を行い、DNSラウンドロビンによりVPNサーバの1台が選定されます。
鍵の寿命が尽きる場合、少し前から並行して鍵交換を行いますので、ダウンタイムはほぼ0です。しかし、スティッキーが存在する訳ではないので、高確率で別のVPNサーバへ接続されます。
また、DPDによりSAのダウンが検出された場合（OpenSwanが動作を停止した場合など）、DPDのタイムアウトを待って、同じく鍵の交換を再度試みます。
参照サイト
あまりにも多すぎてわかりましぇん。。。（Chromeのタブが多すぎて、、、多すぎて、、、。）
おわりに
いつか木崎湖行きたいんですよね。温泉も良さげだけど、キャンプ場で一日読書とかやりたいデス。。。
