FortiGateに接続し、IPsec VPNトンネルを介して継続的インテグレーションサーバーにアクセスしようとしています。
FortiGateの設定を制御できません。
Windows 10を実行しているラップトップで、FortiClientを使用してhttp://ourCIserver:8080
の統合サーバーにアクセスしました。
Arch Linux 4.14.15を実行している他のラップトップで、IPsecトンネルを確立するために strongSwan 5.6.1を使用しています。
心強いことに、Sudo ipsec restart
の最後の部分から判断すると、Sudo ipsec statusall
を呼び出したときにトンネルが確立されているようです。
Status of IKE charon daemon (strongSwan 5.6.1, Linux 4.14.15-1-Arch, x86_64):
uptime: 8 seconds, since Feb 14 15:45:58 2018
malloc: sbrk 2789376, mmap 0, used 869600, free 1919776
worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 5
loaded plugins: <omitted>
Listening IP addresses:
10.0.0.1
Connections:
myConn: %any...vpn.the-vpn-server.com IKEv1 Aggressive, dpddelay=30s
myConn: local: [theuser] uses pre-shared key authentication
myConn: local: [theuser] uses XAuth authentication: any
myConn: remote: uses pre-shared key authentication
myConn: child: dynamic === 10.7.0.0/24 TUNNEL, dpdaction=clear
Shunted Connections:
Bypass LAN 10.0.0.0/24: 10.0.0.0/24 === 10.0.0.0/24 PASS
Bypass LAN ::1/128: ::1/128 === ::1/128 PASS
Bypass LAN fe80::/64: fe80::/64 === fe80::/64 PASS
Security Associations (1 up, 0 connecting):
myConn[1]: ESTABLISHED 7 seconds ago, 10.0.0.1[theuser]...83.xxx.xxx.xx[83.xxx.xxx.xx]
myConn[1]: IKEv1 SPIs: 9ecabd502184611d_i* 1e7f83412c3aa933_r, pre-shared key+XAuth reauthentication in 7 hours
myConn[1]: IKE proposal: <encryption-hash-diffie-hellman-group>
myConn{1}: INSTALLED, TUNNEL, reqid 1, ESP in UDP SPIs: cf636a4c_i 98552ddb_o
myConn{1}: <encryption-hash-diffie-hellman-group>, 0 bytes_i, 0 bytes_o, rekeying in 12 minutes
myConn{1}: 10.0.0.1/32 === 10.7.0.0/24
接続は確立していますが、http://ourCIserver:8080
に接続できません。これは私が達成したいことです。
iptables
またはDNSの一部の構成が不足しているようです。
DNSと言えば、FortiClient(Windows)の構成にこの部分があり、/etc/ipsec.conf
の形式に変換できませんでした。
<use_vip>1</use_vip>
<virtualip>
<type>dhcpoveripsec</type>
<ip>0.0.0.0</ip>
<mask>0.0.0.0</mask>
<dnsserver>0.0.0.0</dnsserver>
<winserver>0.0.0.0</winserver>
</virtualip>
以下は、私が関連すると思うシステムの構成です。他に投稿するものを教えてください。
iptables-save
# Generated by iptables-save v1.6.1 on Wed Feb 14 16:31:09 2018
*filter
:INPUT ACCEPT [5889:5448467]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [4843:436153]
-A INPUT -s 10.7.0.0/24 -d 10.0.0.1/32 -i wlp3s0 -m policy --dir in --pol ipsec --reqid 1 --proto esp -j ACCEPT
-A OUTPUT -s 10.0.0.1/32 -d 10.7.0.0/24 -o wlp3s0 -m policy --dir out --pol ipsec --reqid 1 --proto esp -j ACCEPT
COMMIT
# Completed on Wed Feb 14 16:31:09 2018
ip route
default via 10.0.0.138 dev wlp3s0 src 10.0.0.1 metric 303
10.0.0.0/24 dev wlp3s0 proto kernel scope link src 10.0.0.1 metric 303
ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: enp2s0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
link/ether 00:1e:33:a8:53:c6 brd ff:ff:ff:ff:ff:ff
3: wlp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DORMANT group default qlen 1000
link/ether 00:22:fa:91:3e:02 brd ff:ff:ff:ff:ff:ff
Sudo ip xfrm policy
src 10.0.0.1/32 dst 10.7.0.0/24
dir out priority 371327
tmpl src 10.0.0.1 dst 83.xxx.xxx.xx
proto esp spi 0x98552dde reqid 1 mode tunnel
src 10.7.0.0/24 dst 10.0.0.1/32
dir fwd priority 371327
tmpl src 83.xxx.xxx.xx dst 10.0.0.1
proto esp reqid 1 mode tunnel
src 10.7.0.0/24 dst 10.0.0.1/32
dir in priority 371327
tmpl src 83.xxx.xxx.xx dst 10.0.0.1
proto esp reqid 1 mode tunnel
src fe80::/64 dst fe80::/64
dir fwd priority 134463
src fe80::/64 dst fe80::/64
dir in priority 134463
src fe80::/64 dst fe80::/64
dir out priority 134463
src ::1/128 dst ::1/128
dir fwd priority 68927
src ::1/128 dst ::1/128
dir in priority 68927
src ::1/128 dst ::1/128
dir out priority 68927
src 10.0.0.0/24 dst 10.0.0.0/24
dir fwd priority 175423
src 10.0.0.0/24 dst 10.0.0.0/24
dir in priority 175423
src 10.0.0.0/24 dst 10.0.0.0/24
dir out priority 175423
src 0.0.0.0/0 dst 0.0.0.0/0
socket in priority 0
src 0.0.0.0/0 dst 0.0.0.0/0
socket out priority 0
src 0.0.0.0/0 dst 0.0.0.0/0
socket in priority 0
src 0.0.0.0/0 dst 0.0.0.0/0
socket out priority 0
src ::/0 dst ::/0
socket in priority 0
src ::/0 dst ::/0
socket out priority 0
src ::/0 dst ::/0
socket in priority 0
src ::/0 dst ::/0
socket out priority 0
/etc/ipsec.conf
config setup
charondebug = "dmn 1, mgr 1, ike 2, chd 1, job 1, cfg 3, knl 2, net 2, enc 1, lib 1"
conn myConn
keyexchange = ikev1
ike = <encryption-hash-diffie-hellman-group>
esp = <encryption-hash-diffie-hellman-group>
aggressive = yes
ikelifetime = 28800s
right = 83.xxx.xxx.xx
#right = vpn.the-vpn-server.com
rightsubnet = 10.7.0.0/24
rightid = %any
rightauth = psk
rightdns = 0.0.0.0,8.8.8.8,8.8.4.4
left = %defaultroute
leftauth = psk
leftauth2 = xauth
xauth_identity = "theuser"
auto = start
/etc/ipsec.secrets
# ipsec.secrets - strongSwan IPsec secrets file
: PSK "secret_preshared_key"
: XAUTH "secret_xauth_password"
ユーザーroaimaのアドバイスに従って、CIサーバーにIPアドレスで連絡しました:http://10.7.0.50:8080/
この部分を/etc/ipsec.conf
から削除した後、DNSなしで作業できました:
lifebytes = 5120
lifebytes
は、一定量のバイトを送信した後にセキュリティアソシエーションを期限切れにします。私の場合、クライアントとサーバーは再接続できませんでした。
ログでは、lifebytes
によって引き起こされた有効期限は、
[KNL] received a XFRM_MSG_EXPIRE
CIサーバーのダッシュボードのHTMLをwget -O- --header 'Host: ourCIserver' 10.7.0.50:8080/
からダウンロードできるようになりました。
さらに便利なことに、FirefoxはIPアドレスを使用してCIサーバーに接続し、そのHTMLをレンダリングできます。
これは、接続が機能し、HTTPトラフィックを許可することを意味します。これは朗報です。
追加した
rightdns = 0.0.0.0,8.8.8.8,8.8.4.4
/etc/ipsec.conf
に変換されますが、ping ourCIserver
は
Name or service not known
traceroute ourCIserver
ではまだ運がありません
ourCIserver: Name or service not known
Cannot handle "Host" cmdline arg `ourCIserver' on position 1 (argc 1)
これは、DNSが機能したWindows上のFortiClientのDNS関連の設定です。
<virtualip>
<type>dhcpoveripsec</type>
<ip>0.0.0.0</ip>
<mask>0.0.0.0</mask>
<dnsserver>0.0.0.0</dnsserver>
<winserver>0.0.0.0</winserver>
</virtualip>
/etc/hosts
でIP /ホストマッピングを提供することでDNSの問題を回避できますが、もちろん、トンネルの反対側のサーバーを使用してDNSを取得することをお勧めします。
#<ip-address> <hostname.domain.org> <hostname>
10.7.0.50 ourCIserver ourCIserver
上記の/etc/ipsec.conf
の内容を使用してVPNに接続できます。 DNSは機能しませんが、私には問題ありません。
StrongSwanを使用してFortiGateに接続したい人のために、これらの努力から 回答 を抽出しました。
私はそれを最後に必要としたときに blogged についてそれをしました。主なトリックは、フォーティネットがアグレッシブモードを必要とすることです。そのため、構成パラメーターは最初からすでに厳密に一致している必要があります。
参考までに、私の構成は
conn fortinet
left=%any
leftauth=psk
leftid=""
leftauth2=xauth
xauth_identity="your username"
leftsourceip=%config
right=gateway IP address
rightsubnet=VPN subnet
rightauth=psk
keyexchange=ikev1
aggressive=yes
ike=aes128-sha1-modp1536!
esp=aes128-sha1-modp1536!
auto=add
また、PSKおよびXAUTHシークレットを構成する必要があります。
これは2016年だったので、ikeおよびespモードはより長いキーを使用するように更新されている可能性があります-それぞれに特定の暗号を適用していることに注意してください。