★★★ Step.6 StrongSwan以外に必要そうなヤツいれる ★★★
vpn.ipsec.basics
strongswan のインストール時がちょっと変だったが
vpn.ipsec.basics にも strongswan ではなく strongswan-defaultと書かれているので
strongswan-defaultのインストールが成功し、
strongswan パッケージのインストールが失敗したけどまあいいか。
（後記：strongswan パッケージは無視して、strongswan-full をインストールすべし、strongswanパッケージは-fullを入れれば勝手に入る。入れないとコンフィギャ失敗する)
StrongSwan以外にip、iptables-mod-nat-extra、djbdns-toolsが要るようだ
opkg update ...(略 opkg list ip opkg install ip
opkg list iptables-mod-nat-extra opkg install iptables-mod-nat-extra
opkg list djbdns-tools
むむむむ、んなファイル無い。
djbdns-tools は何故必要とされていたんだろうか？
現状このパッケージは無視の方向。
diff を使いたいので
opkg install diffutils
★★★ Step.7 OpenWRTなマシンをもう一つ作る ★★★
ここまで来て気づいたが、IPSecを試験するには単体では無理だ。VMをクローンする
Oracle VM Virtualbox マネージャ
仮想マシンを選択して クローン(O)
全てのネットワークカードのMACアドレスを再初期化(R)にチェック
シリアルポートの パス/アドレスを変更
\\.\pipe\vbox2
クローン先のネットワークアダプター２はクローン元のアダプター２と独立している必要がある。
Oracle VM Virtualbox マネージャ
ファイル(F)⇒環境設定(P)⇒ネットワーク⇒ホストオンリーネットワーク（H)→+追加
アダプター(A) IPｖ4 アドレス 192.168.178.2 ネットマスク 255.255.255.0
クローンを起動
/etc/conf/network
config interface 'lan'
option ifname 'eth1'
# option type 'bridge'
option proto 'static'
option ipaddr '192.168.178.1'
option netmask '255.255.255.0'
option ip6assign '60'
ここで構成図を書き直した方がいいんだろうな。
HostOnly1[192.168.254.2]<->[192.168.254.1]OpenWRT1[192.168.1.202]<->[192.168.1.116]OpenWRT2[192.168.178.1]<->[192.168.178.2]HostOnly2
で、ホストからはHostOnly
以外に192.168.1/24にもアクセスできる状態。
この状態でOpenWRT1をネットワーク192.168.254.0/24 へのゲートウェイトしてOpenWRT2からIPSec を試みる。
★★★ Step.8 最低限のIPSec connection★★★
ドキュメントを読んでいるとなんかIPSec = VPN という気がしない。
VPNを達成するのにIPSec を使っているだけであって本来は
Ethernet 接続を セキュアにする目的。
そこが設定が難しいと言われる根源なのではないかという気がしてきた。
ikev1 PSK IPv4
の例を参考にする。
OpenWRT1が moon 的位置づけ
OpenWRT2が carol という事になるんだろうなあ。
まずファイヤーウォールをどげんかせんといかん。
まず、INPUT,FORWARD,OUTPUT DROP,REJECT,ACCEPTの意味もよくわかっとらんので
Linuxで作るファイアウォール［パケットフィルタリング設定編］ (1/2)
を読んでみる
おそらくここの設定がOpenWRT の FireWall 設定General Setting のところになるだろうか。
OpenWRT1のWAN->LANは自らサービスを提供するから INPUTはACCEPTにしなければならないだろう。
OUTPUTもACCEPTでいいだろう。FORWARDもACCEPTでいいか。
NAT が要るか要らないか。
現段階では192.168.1.0/24のネットワークだけのハナシで要るようなきがしない。
HostOnlyNetworkにつなぐようになる場合も
適切にStatic Routeを設定さえすれば、いいのではって気がする。
今はとりあえずOFFにしておく。
OpenWRT1は ipsec を誰かに任せるわけではないので今のところPortForwardも設定不要か。
OpenWRT2の方は実際に指定するIPが違うだけでパターンは同じで良さそうだな。
現段階ではかなりのノーガードになってしまうが、こいつがすぐにFirewallになる事もないしDMZに配置されることもないから、遊んでる現状ではこれでいいだろう。
不要なポートの戸締りは実用化段階で検討。
OpenWRT1
/etc/ipsec.conf
config setup
# strictcrlpolicy=yes
# uniqueids = no
conn %default
ikelifetime=60m
keylife=20m
rekeymargin=3m
keyingtries=1
keyexchange=ikev1
authby=secret
conn openwrt2
also=rw
right=192.168.1.116
auto=add
/etc/ipsec.secrets
# /etc/ipsec.secrets - strongSwan IPsec secrets file 192.168.1.202 192.168.1.116 : PSK 0sFpZAZqEN6Ti9sqt4ZP5EWcqx
OpenWRT2
/etc/ipsec.conf
# ipsec.conf - strongSwan IPsec configuration file
# basic configuration
config setup
# strictcrlpolicy=yes
# uniqueids = no
conn %default
ikelifetime=60m
keylife=20m
rekeymargin=3m
keyingtries=1
keyexchange=ikev1
authby=secret
conn home
left=192.168.1.116
leftfirewall=yes
right=192.168.1.202
rightsubnet=192.168.254.0/24
auto=add
/etc/ipsec.secrets
# /etc/ipsec.secrets - strongSwan IPsec secrets file 192.168.1.116 : PSK 0sFpZAZqEN6Ti9sqt4ZP5EWcqx
以降 OpenWRT2から実行
ipsec restart
ipsec up home
なんかつながってはいるようだ。
ただ、暗号化されているかパケットが見えない。
oot@OpenWrt:/etc# ipsec status
no files found matching '/etc/strongswan.d/*.conf'
Security Associations (1 up, 0 connecting):
home[1]: ESTABLISHED 11 minutes ago, 192.168.1.116[192.168.1.116]...192.168.1.202[192.168.1.202]
home{1}: INSTALLED, TUNNEL, reqid 1, ESP SPIs: c326ca0a_i c3dc83fc_o
home{1}: 192.168.1.116/32 === 192.168.254.0/24
root@OpenWrt:/etc# ping 192.168.254.2
PING 192.168.254.2 (192.168.254.2): 56 data bytes
^C
--- 192.168.254.2 ping statistics ---
15 packets transmitted, 0 packets received, 100% packet loss
うーんPINGが通らない。192.168.254.1へは通るようになったが…。
問題切り分けのためにOpenWRT1からtraceroute をすると traceroute 192.168.254.2 が通らない。
traceroute を試してみたがbusybox の traceroute は -I オプションでもICMPを送らないような設定にできるらしく、OpenWRTのbusybox もビルドオプション見てない
CONFIG_FEATURE_TRACEROUTE_USE_ICMP was set to n っぽい。
busybox は Trace route は UDP ガチガチでICMPと結果は違うものになる。
WindowsファイヤーウォールをOFFにしたら traceroute が通るようになったかも。
まさかと思ったがWindows firewall 仕事してるんだ…。
でもやっぱりOpenwrt2 192.168.1.116から192.168.254.2へはPINGもtracerouteも通らない。
Secure connection は張れてるっぽい。でも接続先のGatewayがFirewallになってしまっている状態。
route の設定をちゃんとしても、ポートの設定をどうやって設定してもそっから先に
Pingが飛ばなかった。
うーんとにかくやたらめったにコマンドを打って様子を観察した。
wiresharkをやろうと思ったが、流石にハードルが高いのでtcpdump で観察したり。
原因の一つはルートをちゃんと設定できてなかったこと。
クライアント側はデフォルトルートをIPSEC接続先に変更するくらいの事をして観察すれば、一応は、IPSec 接続先までは暗号化されており、その先へのパケットも飛んでいることがわかる。
だが、問題は接続先の接続先のLANはICMP echo response を返さない事。
何故ならば接続クライアントはPINGパケットを相変わらず自分のIPを設定して送るようだ。GatewayはちゃんとヨソのLANに投げ直してくれているのだけど、応答する側が無視している。
ubuntu 等を見ていると、インターフェイスと同じネットワーク上の端末からのICMP echo request
にはICMP echo responseを返しているようだが、得体の知れないecho request に対しては全くのだんまりであることがわかった。
そういう事であれば
ikev1 PSK IPv4
の設定というのはそのままではなかなかPINGが通らない。という事になるかもしれない。
返事をしてもらうにはNATが要るのだ。
WANからのパケットのIPをLANのIPに書き換え
WANへのパケットのIPを書き戻す設定が必要なのだ。
NATは無くてもパケットは送れる。でも誰も応答してくれない。
ふつうのブロードバンドルータのNATとは逆の考え方になる。
ふつうは中から外なのが、外から中になるわけだから。
でもやっぱりもっといい方法があるハズだ。根本的な問題は、Roadwarrior が内部LANのメンバーになりきれていないという事で、ヨソモノのIPを使っており総スカンを食らっているのが原因だ。
VirtualIPにせよxl2tpd にせよ ローカルネットワーク用のアドレスを割り当ててもらう機能があるハズだから、とりあえず strongswan の根本的な機能を学習できたし、次に進もうかと思う。
0 件のコメント:
コメントを投稿