IPSec/Strongswan - dostęp do domowej sieci


(mktos) #1

Cześć,
chcę mieć dostęp z zewnątrz do sieci domowej, dlatego zestawiam sobie VPN-a. Bramką VPN jest Raspberry Pi, podłączone do routera. Router przepuszcza porty odpowiednie, skonfigurowałem odpowiednie certyfikaty, RPi terminuje połączenie, klient się podłącza… i tyle. Nie mam przekierowania ruchu.

Sieć ma adres 192.168.8.0/24. Klienty VPN powinny dostać adres z podsieci 192.168.9.0/24, i dostają.

Konfiguracja VPN-a:

conn rw-mschapv2
	ikelifetime=60m
	keylife=20m
	rekeymargin=3m
	keyingtries=1
	keyexchange=ikev2
	left=%any
	leftsubnet=192.168.8.0/24
	leftid=[ciach]
	leftsendcert=always
	leftcert=vpnleia.crt
	leftauth=pubkey
	leftfirewall=yes
	right=%any
	rightsourceip=192.168.9.0/24
	rightauth=eap-mschapv2
	rightsendcert=never
	eap_identity=%any
	auto=start
	compress=yes
	esp=aes256-sha384-modp1024
	ike=aes256-sha384-modp1024
	fragmentation=no

Wynik ipsec statusall potwierdza: połączyłem się, działa, uzyskał adres, dodał połączenie:

[root@leia ktos]# ipsec statusall
Status of IKE charon daemon (strongSwan 5.6.2, Linux 4.14.22-1-ARCH, armv6l):
  uptime: 51 seconds, since Mar 04 14:03:05 2018
  malloc: sbrk 802816, mmap 0, used 483728, free 319088
  worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 3
  loaded plugins: charon ldap aes des rc2 sha2 sha3 sha1 md5 mgf1 random nonce x509 revocation constraints pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey sshkey pem openssl fips-prf gmp curve25519 agent chapoly xcbc cmac hmac ntru newhope bliss curl sqlite attr kernel-netlink resolve socket-default bypass-lan connmark forecast farp stroke vici updown eap-identity eap-sim eap-aka eap-aka-3gpp2 eap-simaka-pseudonym eap-simaka-reauth eap-md5 eap-gtc eap-mschapv2 eap-dynamic eap-radius eap-tls eap-ttls eap-peap xauth-generic xauth-eap xauth-pam xauth-noauth dhcp radattr unity counters
Virtual IP pools (size/online/offline):
  192.168.9.0/24: 254/1/0
Listening IP addresses:
  192.168.8.12
Connections:
 rw-mschapv2:  %any...%any  IKEv2
 rw-mschapv2:   local:  [ciach] uses public key authentication
 rw-mschapv2:    cert:  "C=PL, ST=Lubelskie, L=Lublin, O=kilibar.be, CN=[ciach], E=[ciach]"
 rw-mschapv2:   remote: uses EAP_MSCHAPV2 authentication with EAP identity '%any'
 rw-mschapv2:   child:  192.168.8.0/24 === dynamic TUNNEL
Shunted Connections:
Bypass LAN 192.168.8.0/24:  192.168.8.0/24 === 192.168.8.0/24 PASS
Bypass LAN 192.168.8.1/32:  192.168.8.1/32 === 192.168.8.1/32 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):
 rw-mschapv2[2]: ESTABLISHED 43 seconds ago, 192.168.8.12[ciach]...31.0.81.192[10.97.254.90]
 rw-mschapv2[2]: Remote EAP identity: NONA\ktos
 rw-mschapv2[2]: IKEv2 SPIs: bdbacc636be5381e_i 0549c14b01ae058d_r*, public key reauthentication in 54 minutes
 rw-mschapv2[2]: IKE proposal: AES_CBC_256/HMAC_SHA2_384_192/PRF_HMAC_SHA2_384/MODP_1024
 rw-mschapv2{1}:  INSTALLED, TUNNEL, reqid 1, ESP in UDP SPIs: c6c41067_i 5a623594_o
 rw-mschapv2{1}:  AES_CBC_256/HMAC_SHA1_96, 0 bytes_i, 360 bytes_o (6 pkts, 12s ago), rekeying in 14 minutes
 rw-mschapv2{1}:   192.168.8.0/24 === 192.168.9.1/32

Więc strzelam, że problem jest gdzieś w okolicach iptables, ale wydaje mi się, że jest wszystko dobrze:


# Generated by iptables-save v1.6.2 on Sun Mar  4 14:11:00 2018
*nat
:PREROUTING ACCEPT [126:39412]
:INPUT ACCEPT [126:39412]
:OUTPUT ACCEPT [46:3301]
:POSTROUTING ACCEPT [38:2821]
-A POSTROUTING -m policy --dir out --pol ipsec -j ACCEPT
-A POSTROUTING -o eth0 -m policy --dir out --pol ipsec -j ACCEPT
-A POSTROUTING -s 192.168.9.0/24 -o eth0 -m policy --dir out --pol ipsec -j ACCEPT
-A POSTROUTING -s 192.168.9.0/24 -o eth0 -j MASQUERADE
COMMIT
# Completed on Sun Mar  4 14:11:01 2018
# Generated by iptables-save v1.6.2 on Sun Mar  4 14:11:01 2018
*filter
:INPUT ACCEPT [79:7511]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [57:5302]
-A INPUT -p udp -m udp --dport 4500 -j ACCEPT
-A INPUT -p udp -m udp --dport 500 -j ACCEPT
-A INPUT -p esp -j ACCEPT
COMMIT
# Completed on Sun Mar  4 14:11:01 2018

Przekierowanie też jest zrobione:

[root@leia ~]# cat /proc/sys/net/ipv4/ip_forward
1

Nie działa - kiedy łączę się z hostem 192.168.8.10 to nie mogę się połączyć żadnym protokołem (ani HTTP, ani RDP).

tcpdump też komunikacji nie widzi:

[root@leia ktos]# tcpdump -v -n src 192.168.9.1
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
^C
0 packets captured
0 packets received by filter
0 packets dropped by kernel

Macie jakiś pomysł?


(roobal) #2

Router zna trasę do sieci 192.168.9.0/24?


(mktos) #3

Nie. Niestety, nie jestem w stanie mu nawet jej dodać.

Ale po to robię maskaradę?


(roobal) #4

Wiem, że robisz maskaradę, ale to nie routing. Zrób SNAT zamiast maskarady. Poza tym przy maskaradzie używa się interfejsu wyjściowego bez podawania podsieci.

Dlaczego nie możesz dodać trasy na routerze?