Я играю с StrongSwan в качестве поставщика VPN для нескольких личных проектов, поэтому я запускаю его на том же сервере, что и другие вещи, которые я делаю. Все настроено и работает, однако у меня проблема с доступом к службам (например, nginx) на том же сервере.
Следующие два параметра присутствуют в ipsec.conf файл:
leftfirewall=yes
lefthostaccess=yes
Когда я могу подключиться к VPN, я вижу, что необходимые правила маршрутизации и брандмауэра добавлены следующим образом:
Брандмауэр
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
169 21051 ACCEPT all -- eth0 any 10.11.12.1 anywhere policy match dir in pol ipsec reqid 2 proto esp
133 34163 ACCEPT all -- any eth0 anywhere 10.11.12.1 policy match dir out pol ipsec reqid 2 proto esp
Список маршрутов (таблица 220)
10.11.12.1 via [server ip] dev eth0 proto static
Когда я проверяю входящие и отбрасываемые пакеты, я вижу, что исходный IP-адрес не принадлежит VPN (т.е. трафик не маршрутизируется через VPN). Я знаю, что подключен (из ipsec statusall а также проверив "какой у меня ip").
Таким образом, проблема, похоже, в том, что трафик не направляется в VPN. Это проблема на стороне сервера или проблема с устройством, подключенным к VPN? Весь веб-трафик настроен на прохождение через VPN (что проверяется путем проверки того, какой IP-адрес видят другие веб-сайты).
Я видел этот похожий вопрос, но, насколько я понимаю, ответ на самом деле не дает правильного решения.
Согласно Ecdsa предложение, вот немного дополнительной информации и разъяснений.
Удаленный пользователь (с общедоступным IP-адресом A.A.A.A) подключается к VPN-серверу (с общедоступным IP-адресом B.B.B.B). На этом же сервере работает сервер nginx. Удаленный пользователь может получить доступ к этому серверу из TLD, который указывает на B.B.B.B.
При подключении к VPN (как показано ниже) пользователю правильно назначается IP-адрес из виртуального IP-пула. Если пользователь выполняет следующую команду: curl icanhazip.com вывод - это IP-адрес VPN-сервера (B.B.B.B).
Теперь при подключении к VPN, если пользователь пытается получить доступ к серверу nginx через TLD, пакеты, похоже, не маршрутизируются через VPN. Итак, моя проблема заключается в том, чтобы маршрутизировать пакеты, предназначенные для того же сервера, на котором находится VPN, через VPN.
ipsec statusall
Status of IKE charon daemon (strongSwan 5.3.5, Linux 4.4.0-119-generic, x86_64):
uptime: 111 seconds, since Apr 09 12:15:11 2018
malloc: sbrk 1642496, mmap 0, used 581936, free 1060560
worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 2
loaded plugins: charon test-vectors aes rc2 sha1 sha2 md4 md5 random nonce x509 revocation constraints pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey sshkey pem openssl fips-prf gmp agent xcbc hmac gcm attr kernel-netlink resolve socket-default connmark farp stroke updown eap-identity eap-sim eap-sim-pcsc 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 eap-tnc xauth-generic xauth-eap xauth-pam xauth-noauth tnc-tnccs tnccs-20 tnccs-11 tnccs-dynamic dhcp lookip error-notify certexpire led addrblock unity
Virtual IP pools (size/online/offline):
10.11.12.0/24: 254/1/0
Listening IP addresses:
SERVER_IP
Connections:
ikev2-vpn: %any...%any IKEv2, dpddelay=300s
ikev2-vpn: local: [vpn.TLD.co.uk] uses public key authentication
ikev2-vpn: cert: "CN=vpn.TLD.co.uk"
ikev2-vpn: remote: uses EAP_MSCHAPV2 authentication with EAP identity '%any'
ikev2-vpn: child: 0.0.0.0/0 === dynamic TUNNEL, dpdaction=clear
Security Associations (1 up, 0 connecting):
ikev2-vpn[1]: ESTABLISHED 4 seconds ago, SERVER_IP[vpn.TLD.co.uk]...REMOTE_IP[vpn.TLD.co.uk]
ikev2-vpn[1]: Remote EAP identity: USER
ikev2-vpn[1]: IKEv2 SPIs: 38003da03964bd2d_i 83715a1671973e21_r*, rekeying disabled
ikev2-vpn[1]: IKE proposal: AES_GCM_16_256/PRF_HMAC_SHA2_256/ECP_521
ikev2-vpn{1}: INSTALLED, TUNNEL, reqid 1, ESP in UDP SPIs: c6f1750a_i 00b2ead4_o
ikev2-vpn{1}: AES_GCM_16_256, 174 bytes_i (3 pkts, 2s ago), 502 bytes_o (3 pkts, 2s ago), rekeying disabled
ikev2-vpn{1}: 0.0.0.0/0 === 10.11.12.1/32
Журнал подключений:
Apr 9 12:59:00 mmstr charon: 11[NET] received packet: from REMOTE_IP[627] to SERVER_IP[500] (300 bytes)
Apr 9 12:59:00 mmstr charon: 11[ENC] parsed IKE_SA_INIT request 0 [ SA KE No N(REDIR_SUP) N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) ]
Apr 9 12:59:00 mmstr charon: 11[IKE] REMOTE_IP is initiating an IKE_SA
Apr 9 12:59:00 mmstr charon: 11[IKE] remote host is behind NAT
Apr 9 12:59:00 mmstr charon: 11[ENC] generating IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(MULT_AUTH) ]
Apr 9 12:59:00 mmstr charon: 11[NET] sending packet: from SERVER_IP[500] to REMOTE_IP[627] (316 bytes)
Apr 9 12:59:00 mmstr charon: 13[NET] received packet: from REMOTE_IP[19603] to SERVER_IP[4500] (352 bytes)
Apr 9 12:59:00 mmstr charon: 13[ENC] unknown attribute type (25)
Apr 9 12:59:00 mmstr charon: 13[ENC] parsed IKE_AUTH request 1 [ IDi N(INIT_CONTACT) N(MOBIKE_SUP) IDr CPRQ(ADDR DHCP DNS MASK ADDR6 DHCP6 DNS6 (25)) N(ESP_TFC_PAD_N) N(NON_FIRST_FRAG) SA TSi TSr N(EAP_ONLY) ]
Apr 9 12:59:00 mmstr charon: 13[IKE] initiating EAP_IDENTITY method (id 0x00)
Apr 9 12:59:00 mmstr charon: 13[IKE] received ESP_TFC_PADDING_NOT_SUPPORTED, not using ESPv3 TFC padding
Apr 9 12:59:00 mmstr charon: 13[IKE] peer supports MOBIKE
Apr 9 12:59:00 mmstr charon: 13[IKE] authentication of 'vpn.TLD.co.uk' (myself) with RSA signature successful
Apr 9 12:59:00 mmstr charon: 13[IKE] sending end entity cert "CN=vpn.TLD.co.uk"
Apr 9 12:59:00 mmstr charon: 13[ENC] generating IKE_AUTH response 1 [ IDr CERT AUTH EAP/REQ/ID ]
Apr 9 12:59:00 mmstr charon: 13[ENC] splitting IKE message with length of 2415 bytes into 5 fragments
Apr 9 12:59:00 mmstr charon: 13[ENC] generating IKE_AUTH response 1 [ EF(1/5) ]
Apr 9 12:59:00 mmstr charon: 13[ENC] generating IKE_AUTH response 1 [ EF(2/5) ]
Apr 9 12:59:00 mmstr charon: 13[ENC] generating IKE_AUTH response 1 [ EF(3/5) ]
Apr 9 12:59:00 mmstr charon: 13[ENC] generating IKE_AUTH response 1 [ EF(4/5) ]
Apr 9 12:59:00 mmstr charon: 13[ENC] generating IKE_AUTH response 1 [ EF(5/5) ]
Apr 9 12:59:00 mmstr charon: 13[NET] sending packet: from SERVER_IP[4500] to REMOTE_IP[19603] (544 bytes)
Apr 9 12:59:00 mmstr charon: message repeated 3 times: [ 13[NET] sending packet: from SERVER_IP[4500] to REMOTE_IP[19603] (544 bytes)]
Apr 9 12:59:00 mmstr charon: 13[NET] sending packet: from SERVER_IP[4500] to REMOTE_IP[19603] (487 bytes)
Apr 9 12:59:00 mmstr charon: 12[NET] received packet: from REMOTE_IP[19603] to SERVER_IP[4500] (80 bytes)
Apr 9 12:59:00 mmstr charon: 12[ENC] parsed IKE_AUTH request 2 [ EAP/RES/ID ]
Apr 9 12:59:00 mmstr charon: 12[IKE] received EAP identity 'USER'
Apr 9 12:59:00 mmstr charon: 12[IKE] initiating EAP_MSCHAPV2 method (id 0x10)
Apr 9 12:59:00 mmstr charon: 12[ENC] generating IKE_AUTH response 2 [ EAP/REQ/MSCHAPV2 ]
Apr 9 12:59:00 mmstr charon: 12[NET] sending packet: from SERVER_IP[4500] to REMOTE_IP[19603] (97 bytes)
Apr 9 12:59:00 mmstr charon: 14[NET] received packet: from REMOTE_IP[19603] to SERVER_IP[4500] (128 bytes)
Apr 9 12:59:00 mmstr charon: 14[ENC] parsed IKE_AUTH request 3 [ EAP/RES/MSCHAPV2 ]
Apr 9 12:59:00 mmstr charon: 14[ENC] generating IKE_AUTH response 3 [ EAP/REQ/MSCHAPV2 ]
Apr 9 12:59:00 mmstr charon: 14[NET] sending packet: from SERVER_IP[4500] to REMOTE_IP[19603] (134 bytes)
Apr 9 12:59:00 mmstr charon: 15[NET] received packet: from REMOTE_IP[19603] to SERVER_IP[4500] (72 bytes)
Apr 9 12:59:00 mmstr charon: 15[ENC] parsed IKE_AUTH request 4 [ EAP/RES/MSCHAPV2 ]
Apr 9 12:59:00 mmstr charon: 15[IKE] EAP method EAP_MSCHAPV2 succeeded, MSK established
Apr 9 12:59:00 mmstr charon: 15[ENC] generating IKE_AUTH response 4 [ EAP/SUCC ]
Apr 9 12:59:00 mmstr charon: 15[NET] sending packet: from SERVER_IP[4500] to REMOTE_IP[19603] (65 bytes)
Apr 9 12:59:00 mmstr charon: 16[NET] received packet: from REMOTE_IP[19603] to SERVER_IP[4500] (104 bytes)
Apr 9 12:59:00 mmstr charon: 16[ENC] parsed IKE_AUTH request 5 [ AUTH ]
Apr 9 12:59:00 mmstr charon: 16[IKE] authentication of 'vpn.TLD.co.uk' with EAP successful
Apr 9 12:59:00 mmstr charon: 16[IKE] authentication of 'vpn.TLD.co.uk' (myself) with EAP
Apr 9 12:59:00 mmstr charon: 16[IKE] IKE_SA ikev2-vpn[2] established between SERVER_IP[vpn.TLD.co.uk]...REMOTE_IP[vpn.TLD.co.uk]
Apr 9 12:59:00 mmstr charon: 16[IKE] peer requested virtual IP %any
Apr 9 12:59:00 mmstr charon: 16[IKE] assigning virtual IP 10.11.12.1 to peer 'USER'
Apr 9 12:59:00 mmstr charon: 16[IKE] peer requested virtual IP %any6
Apr 9 12:59:00 mmstr charon: 16[IKE] no virtual IP found for %any6 requested by 'USER'
Apr 9 12:59:00 mmstr charon: 16[IKE] CHILD_SA ikev2-vpn{2} established with SPIs cebf4aaa_i 00674f97_o and TS 0.0.0.0/0 === 10.11.12.1/32
Apr 9 12:59:00 mmstr kernel: [ 2641.863504] audit: type=1400 audit(1523278740.562:21): apparmor="DENIED" operation="open" profile="/usr/lib/ipsec/charon" name="/proc/3338/fd/" pid=3338 comm="charon" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
Apr 9 12:59:00 mmstr vpn: + vpn.TLD.co.uk 10.11.12.1/32 == REMOTE_IP -- SERVER_IP == 0.0.0.0/0
Apr 9 12:59:00 mmstr charon: 16[ENC] generating IKE_AUTH response 5 [ AUTH CPRP(ADDR DNS DNS) SA TSi TSr N(MOBIKE_SUP) N(ADD_4_ADDR) ]
Apr 9 12:59:00 mmstr charon: 16[NET] sending packet: from SERVER_IP[4500] to REMOTE_IP[19603] (233 bytes)
Это сброшенный пакет
Apr 9 13:04:12 mmstr kernel: [ 2953.930182] IPTables-Dropped: IN=eth0 OUT= MAC=*** SRC=REMOTE_IP DST=SERVER_IP LEN=60 TOS=0x00 PREC=0x00 TTL=53 ID=41666 DF PROTO=TCP SPT=5578 DPT=443 WINDOW=29200 RES=0x00 SYN URGP=0
Важно отметить, что источником пакета является исходный IP-адрес удаленного пользователя (то есть A.A.A.A).
Это конфигурация брандмауэра iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
ACCEPT all -- 10.11.12.1 anywhere policy match dir in pol ipsec reqid 2 proto esp
DROP all -- anywhere anywhere state NEW recent: UPDATE seconds: 60 hit_count: 12 name: DEFAULT side: source mask: 255.255.255.255
all -- anywhere anywhere state NEW recent: SET name: DEFAULT side: source mask: 255.255.255.255
ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
ACCEPT all -- anywhere anywhere
DROP all -- anywhere anywhere state INVALID
ACCEPT tcp -- anywhere anywhere tcp dpt:ssh
ACCEPT udp -- anywhere anywhere udp dpt:isakmp
ACCEPT udp -- anywhere anywhere udp dpt:ipsec-nat-t
LOGGING tcp -- anywhere anywhere tcp dpt:http
LOGGING tcp -- anywhere anywhere tcp dpt:https
DROP all -- anywhere anywhere
Chain FORWARD (policy ACCEPT)
target prot opt source destination
ACCEPT all -- 10.11.12.1 anywhere policy match dir in pol ipsec reqid 2 proto esp
ACCEPT all -- anywhere 10.11.12.1 policy match dir out pol ipsec reqid 2 proto esp
ACCEPT all -- 10.11.12.0/24 anywhere policy match dir in pol ipsec proto esp
ACCEPT all -- anywhere 10.11.12.0/24 policy match dir out pol ipsec proto esp
DROP all -- anywhere anywhere
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
ACCEPT all -- anywhere 10.11.12.1 policy match dir out pol ipsec reqid 2 proto esp
Chain LOGGING (2 references)
target prot opt source destination
LOG all -- anywhere anywhere limit: avg 2/min burst 5 LOG level warning prefix "IPTables-Dropped: "
DROP all -- anywhere anywhere