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