Falta regras iptables para o roteamento Strongswan para VPN por telefone

2

Eu tenho um Centos 6.6 VPS na Internet que tem um IP público. Instalei o StrongSwan 5.1.3 para permitir que meu telefone BlackBerry10 se conecte a partir de pontos de acesso e use a conexão do VPS. O IP do VPS mostra quando eu vou para www.whatismyip.com, e então eu acho que essa parte está funcionando bem.

Gostaria agora de fazer algum desenvolvimento / teste onde, quando o telefone estiver ligado ao VPS, gostaria que o VPS pudesse aceder ao telefone usando o IP que lhe foi atribuído pela Strongswan. (ou seja, ping 192.168.179.101, https para 192.168.179.101) No entanto, eu não acho que o Centos saiba como obter o tráfego para esse cliente específico. O que muda para StrongSwan e / ou iptables seria necessário para permitir que isso acontecesse?

Aqui está o meu ipsec.conf:

config setup
strictcrlpolicy=no

conn %default
ikelifetime=24h
keylife=24h
keyexchange=ikev2
dpdaction=clear
dpdtimeout=3600s
dpddelay=3600s
compress=yes

conn rem
rekey=no
leftsubnet=0.0.0.0/0
leftauth=psk
leftid=162.244.xxx.xxx
right=%any
rightsourceip=192.168.179.100/29
rightauth=eap-mschapv2
rightsendcert=never
eap_identity=%any
auto=add

iptables -L

Chain INPUT (policy ACCEPT)
target     prot opt source               destination
fail2ban-SSH  tcp  --  anywhere             anywhere            tcp dpt:ssh
ACCEPT     tcp  --  anywhere             anywhere            multiport dports http,https
fail2ban-SSH  tcp  --  anywhere             anywhere            tcp dpt:ssh
ACCEPT     udp  --  anywhere             anywhere            udp dpt:l2tp
ACCEPT     udp  --  anywhere             anywhere            udp dpt:ipsec-nat-t
ACCEPT     udp  --  anywhere             anywhere            udp dpt:isakmp

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination
TCPMSS     tcp  --  anywhere             anywhere            tcp flags:SYN,RST/SYN TCPMSS clamp to PMTU

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Chain fail2ban-SSH (2 references)
target     prot opt source               destination
REJECT     all  --  static-108-35-57-14.nwrknj.fios.verizon.net  anywhere            reject-with icmp-port-unreachable
RETURN     all  --  anywhere             anywhere
RETURN     all  --  anywhere             anywhere

política xfrm ip

src 192.168.179.101/32 dst 0.0.0.0/0
        dir fwd priority 1923 ptype main
        tmpl src 207.81.yy.x dst 162.244.xx.yy
                proto esp reqid 1 mode tunnel
src 192.168.179.101/32 dst 0.0.0.0/0
        dir in priority 1923 ptype main
        tmpl src 207.81.yy.x dst 162.244.xx.yy
                proto esp reqid 1 mode tunnel
src 0.0.0.0/0 dst 192.168.179.101/32
        dir out priority 1923 ptype main
        tmpl src 162.244.xx.yy dst 207.81.yy.x
                proto esp reqid 1 mode tunnel
src 0.0.0.0/0 dst 0.0.0.0/0
        dir 3 priority 0 ptype main
src 0.0.0.0/0 dst 0.0.0.0/0
        dir 4 priority 0 ptype main
src 0.0.0.0/0 dst 0.0.0.0/0
        dir 3 priority 0 ptype main
src 0.0.0.0/0 dst 0.0.0.0/0
        dir 4 priority 0 ptype main
src ::/0 dst ::/0
        dir 3 priority 0 ptype main
src ::/0 dst ::/0
        dir 4 priority 0 ptype main
src ::/0 dst ::/0
        dir 3 priority 0 ptype main
src ::/0 dst ::/0
        dir 4 priority 0 ptype main

ipsec statusall

Status of IKE charon daemon (strongSwan 5.1.3, Linux 2.6.32-504.el6.x86_64, x86_64):
  uptime: 19 minutes, since Nov 11 18:58:51 2014
  malloc: sbrk 503808, mmap 0, used 398608, free 105200
  worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 1
  loaded plugins: charon curl ldap pkcs11 aes des rc2 sha1 sha2 md4 md5 random nonce x509 revocation constraints pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey sshkey pem openssl fips-prf gmp xcbc cmac hmac ccm gcm attr kernel-netlink resolve socket-default farp stroke updown eap-identity eap-aka eap-aka-3gpp2 eap-md5 eap-gtc eap-mschapv2 eap-dynamic eap-radius eap-tls eap-ttls eap-peap eap-tnc xauth-generic xauth-eap tnc-tnccs dhcp
Virtual IP pools (size/online/offline):
  192.168.179.100/29: 6/1/0
Listening IP addresses:
  162.244.xx.yy
Connections:
         rem:  %any...%any  IKEv2, dpddelay=3600s
         rem:   local:  [162.244.xx.yy] uses pre-shared key authentication
         rem:   remote: uses EAP_MSCHAPV2 authentication with EAP identity '%any'
         rem:   child:  0.0.0.0/0 === dynamic TUNNEL, dpdaction=clear
Security Associations (1 up, 0 connecting):
         rem[1]: ESTABLISHED 19 minutes ago, 162.244.xx.yy[162.244.xx.yy]...207.81.yy.x[192.168.2.147]
         rem[1]: Remote EAP identity: Swan
         rem[1]: IKEv2 SPIs: 19996d366fee522a_i b35b5ed8c1720f74_r*, rekeying disabled
         rem[1]: IKE proposal: 3DES_CBC/HMAC_MD5_96/PRF_HMAC_MD5/MODP_1024
         rem{1}:  INSTALLED, TUNNEL, ESP in UDP SPIs: c75f570c_i 7a0f8418_o
         rem{1}:  AES_CBC_128/HMAC_SHA1_96, 123827 bytes_i (740 pkts, 3s ago), 358585 bytes_o (724 pkts, 3s ago), rekeying disabled
         rem{1}:   0.0.0.0/0 === 192.168.179.101/32

regras iptables (portas UDP 500, 4500 e 1701 devem ser abertas)

iptables -I POSTROUTING -t nat -o eth0 -j MASQUERADE
iptables -I FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
iptables -I INPUT -p udp --dport 500 -j ACCEPT
iptables -I INPUT -p udp --dport 4500 -j ACCEPT
iptables -I INPUT -p udp --dport 1701 -j ACCEPT

/etc/sysctl.conf

net.ipv4.ip_forward = 1
net.net.ipv4.conf.default.proxy_arp = 1
net.ipv4.conf.default.arp_accept = 1
net.ipv4.conf.default.proxy_arp_pvlan = 1
net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.default.accept_source_route = 0
kernel.sysrq = 0
kernel.core_uses_pid = 1
net.ipv4.tcp_syncookies = 1
kernel.msgmnb = 65536
kernel.msgmax = 65536
kernel.shmmax = 68719476736
kernel.shmall = 4294967296
net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1

Quais mudanças no StrongSwan e / ou iptables seriam necessárias para permitir que eu acesse o cliente pelo IP do próprio servidor StrongSwan?

Muito obrigado antecipadamente !!!

    
por Timbo 12.11.2014 / 01:26

1 resposta

1

Parece que as regras da tabela de entrada do iptables não permitem pacotes ESP. Você pode tentar adicionar "iptables -A INPUT -pesp -j ACCEPT" ao iptables.

    
por 18.01.2016 / 21:09