Я пытаюсь настроить openvpn на Amazon EC2. Чтобы проверить это, я использую http://whatismyipaddress.com.
В настоящее время я могу подключиться к своему удаленному серверу с помощью:
sudo openvpn --config /etc/openvpn/openvpnuser1.conf
После подключения в журнале сервера есть:
Sun Jun 11 08:44:06 2017 us=235368 GET INST BY REAL: 176.XX.193.73:54967 [succeeded]
Sun Jun 11 08:44:06 2017 us=235386 user1/176.XX.193.73:54967 UDPv4 READ [69] from [AF_INET]176.XX.193.73:54967: P_DATA_V1 kid=0 DATA 117650fd 4f53ac24 d1614c31 f40cd5d1 49c86aa0 066fc87e 7e1db1fb 47321f9[more...]
Sun Jun 11 08:44:06 2017 us=235393 user1/176.XX.193.73:54967 TLS: tls_pre_decrypt, key_id=0, IP=[AF_INET]176.XX.193.73:54967
Sun Jun 11 08:44:06 2017 us=235405 user1/176.XX.193.73:54967 DECRYPT IV: 066fc87e 7e1db1fb 47321f94 d4f764ee
Sun Jun 11 08:44:06 2017 us=235416 user1/176.XX.193.73:54967 DECRYPT TO: 00000008 fa2a187b f3641eb4 cb07ed2d 0a981fc7 48
Sun Jun 11 08:44:06 2017 us=235425 user1/176.XX.193.73:54967 PID_TEST [0] [SSL-0] [>EEEEEE] 0:7 0:8 t=1497170646[0] r=[0,64,15,0,1] sl=[57,7,64,528]
Sun Jun 11 08:44:06 2017 us=235431 user1/176.XX.193.73:54967 RECEIVED PING PACKET
Sun Jun 11 08:44:06 2017 us=235437 PO_CTL rwflags=0x0001 ev=4 arg=0x55687fb01180
Sun Jun 11 08:44:06 2017 us=235441 PO_CTL rwflags=0x0001 ev=5 arg=0x55687fb01068
Sun Jun 11 08:44:06 2017 us=235448 I/O WAIT TR|Tw|SR|Sw [8/142628]
Также клиент поднял дополнительный интерфейс и получил IP-адрес (ifconfig):
tun1 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:10.0.0.6 P-t-P:10.0.0.5 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
Итак, я предполагаю, что соединение openvpn установлено. Но, к сожалению, http://whatismyipaddress.com по-прежнему показывает мой (клиентский) реальный IP-адрес.
Конфигурация клиента:
client
dev tun
proto udp
remote 52.XX.48.224 1194
resolv-retry infinite
nobind
persist-key
persist-tun
ca /etc/openvpn/ca.crt
cert /etc/openvpn/user1.crt
key /etc/openvpn/user1.key
tls-auth /etc/openvpn/ccd/ta.key 1
cipher AES-256-CBC
ns-cert-type server
comp-lzo
log /var/log/openvpn.log
verb 3
sndbuf 0
rcvbuf 0
Конфигурация сервера:
port 1194
proto udp
dev tun
ca /etc/openvpn/ca.crt
cert /etc/openvpn/ServerV1.crt
key /etc/openvpn/ServerV1.key
dh /etc/openvpn/dh2048.pem
tls-auth /etc/openvpn/ccd/ta.key 0
cipher AES-256-CBC
server 10.0.0.0 255.255.255.0
keepalive 10 120
persist-key
persist-tun
client-config-dir /etc/openvpn/ccd
status ServerV1-status.log
log /var/log/ServerV1.log
sndbuf 0
rcvbuf 0
push "redirect-geteway def1"
push "dhcp-options DNS 8.8.8.8"
comp-lzo
verb 15
Перенаправление сервера включено
cat /proc/sys/net/ipv4/conf/all/forwarding
1
iptables отредактирован с помощью:
iptables -t nat -A POSTROUTING -s 10.0.0.0/24 -o eth1 -j MASQUERADE
iptables -L -t nat
Chain PREROUTING (policy ACCEPT)
target prot opt source destination
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
Chain POSTROUTING (policy ACCEPT)
target prot opt source destination
MASQUERADE all -- ip-10-0-0-0.eu-central-1.compute.internal/24 anywhere
Грм. Я думаю, вы могли бы быть более явным в конфигурации iptables.
#Allow new OpenVPN connections from the outside
iptables -A INPUT -i eth1 -m state --state NEW -p udp --dport 1194 -j ACCEPT
# Allow all tun interfaces to talk to me
iptables -A input -i tun+ -j ACCEPT
# And to talk through me
iptables -A FORWARD -i tun+ -j ACCEPT
iptables -A FORWARD -i tun+ -o eth1 -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A FORWARD -i eth1 -o tun+ -m state --state RELATED,ESTABLISHED -j ACCEPT
В верхней части вашей конфигурации вы должны исправить ... ваша политика по умолчанию везде - accept, и ваша маскарадная линия выглядит нормально ... ваш трафик не проходит через туннель после его отмены (0 RX / 0 TX) , потому что вы ничего не добавили в свою цепочку ввода ....
Похоже, у вас есть опечатка в конфигурации вашего сервера:
push "redirect-geteway def1"
должно быть
push "redirect-gateway def1"
и это может быть причиной того, что клиент не устанавливает маршрут по умолчанию через туннель после того, как он установлен.
Надеюсь, поможет!