web-dev-qa-db-ja.com

strongSwanからFortiGateへのIPsec VPN

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"

DNSなしで接続する✔️

ユーザー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トラフィックを許可することを意味します。これは朗報です。

DNSとの接続

追加した

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に接続したい人のために、これらの努力から 回答 を抽出しました。

vpnipsecstrongswan
7
Matthias Braun

私はそれを最後に必要としたときに 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モードはより長いキーを使用するように更新されている可能性があります-それぞれに特定の暗号を適用していることに注意してください。

1
Simon Richter