VPN IPsec com strongSwan para FortiGate

Question

Estou tentando conectar-me a um FortiGate e acessar nosso servidor de integração contínua por meio de um túnel VPN IPsec.

Eu não tenho controle sobre a configuração do FortiGate.

No meu laptop executando o Windows 10, usei com êxito o FortiClient para acessar o servidor de integração em http://ourCIserver:8080 .

Agora, com meu outro laptop executando o Arch Linux 4.14.15, estou usando o strongSwan 5.6.1 para estabelecer o túnel IPsec.

Incentivadoramente, o túnel parece ser estabelecido ao chamar sudo ipsec restart , a julgar pela última parte de 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

Embora a conexão esteja ativa, não consigo me conectar a http://ourCIserver:8080 , que é o que eu gostaria de alcançar.

Suspeito que falta alguma configuração em iptables ou DNS.

Falando em DNS, há essa parte na configuração do FortiClient (Windows) que não consegui traduzir no formato /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>

Configuração do Sistema

O que se segue é a configuração do meu sistema que considero relevante; deixe-me saber o que mais postar.

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"

Conectando sem DNS ✔️

Seguindo o conselho do usuário roaima, entrei em contato com o servidor de IC por seu endereço IP: http://10.7.0.50:8080/

Indo menos para o DNS funcionou após remover esta parte de /etc/ipsec.conf :

lifebytes = 5120

lifebytes faz a associação de segurança expirar após a transmissão de uma certa quantidade de bytes. Cliente e servidor não puderam se reconectar no meu caso.

No log, a expiração causada por lifebytes aparece como

[KNL] received a XFRM_MSG_EXPIRE

Agora posso baixar o HTML do painel do nosso servidor de CI por meio de wget -O- --header 'Host: ourCIserver' 10.7.0.50:8080/ .

Ainda mais útil, o Firefox pode se conectar ao servidor de IC usando o endereço IP e renderizar esse HTML.

Isso significa que a conexão funciona agora e permite o tráfego HTTP, o que é uma ótima notícia.

Conectando com DNS

eu adicionei

rightdns = 0.0.0.0,8.8.8.8,8.8.4.4

para /etc/ipsec.conf , mas ping ourCIserver falha com

Name or service not known

Sem sorte ainda com traceroute ourCIserver

ourCIserver: Name or service not known
Cannot handle "host" cmdline arg 'ourCIserver' on position 1 (argc 1)

Esta é uma configuração relacionada ao DNS para o FortiClient no Windows, onde o DNS funcionava:

<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>

Eu posso resolver o problema do DNS fornecendo o mapeamento de IP / host em /etc/hosts , mas é claro que seria preferível obter DNS usando o servidor na outra extremidade do túnel.

#<ip-address>   <hostname.domain.org>   <hostname>
10.7.0.50       ourCIserver             ourCIserver