Кажется, я столкнулся со странной проблемой при настройке OpenVPN на экземпляре AWS EC2 (Ubuntu AMI). Соединение устанавливается, двухфакторная аутентификация проходит, но после подключения клиент не может получить доступ к Интернету.
Для отладки запустил бесконечный пинг на клиенте:
$ ping 87.250.250.242
PING 87.250.250.242 (87.250.250.242): 56 data bytes
64 bytes from 87.250.250.242: icmp_seq=0 ttl=54 time=33.589 ms
64 bytes from 87.250.250.242: icmp_seq=1 ttl=54 time=31.275 ms
64 bytes from 87.250.250.242: icmp_seq=2 ttl=54 time=42.907 ms
64 bytes from 87.250.250.242: icmp_seq=3 ttl=54 time=49.470 ms
64 bytes from 87.250.250.242: icmp_seq=4 ttl=54 time=29.772 ms
На сервере тестирую, как далеко уходит пакет. Это достигает tun0 интерфейс:
$ sudo tcpdump -i tun0 icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun0, link-type RAW (Raw IP), capture size 262144 bytes
08:52:10.261730 IP ip-10-8-1-6.ec2.internal > ya.ru: ICMP echo request, id 52451, seq 2684, length 64
08:52:11.264706 IP ip-10-8-1-6.ec2.internal > ya.ru: ICMP echo request, id 52451, seq 2685, length 64
08:52:12.268201 IP ip-10-8-1-6.ec2.internal > ya.ru: ICMP echo request, id 52451, seq 2686, length 64
08:52:13.272732 IP ip-10-8-1-6.ec2.internal > ya.ru: ICMP echo request, id 52451, seq 2687, length 64
08:52:14.275066 IP ip-10-8-1-6.ec2.internal > ya.ru: ICMP echo request, id 52451, seq 2688, length 64
Однако дальше дело не идет - eth0 не видит:
$ sudo tcpdump -i eth0 icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
Интернет из инстанса EC2 полностью доступен:
$ curl google.com
<HTML><HEAD><meta http-equiv="content-type" content="text/html;charset=utf-8">
<TITLE>301 Moved</TITLE></HEAD><BODY>
<H1>301 Moved</H1>
The document has moved
<A HREF="http://www.google.com/">here</A>.
</BODY></HTML>
Похоже на типичную неправильную конфигурацию постмаршрутизации NAT, но я трижды проверил, все ли настроено должным образом.
Переадресация IP включена:
$ cat /proc/sys/net/ipv4/ip_forward
1
Правило постмаршрутизации в iptables настоящее:
$ sudo iptables -t nat -L
Chain PREROUTING (policy ACCEPT)
target prot opt source destination
DOCKER all -- anywhere anywhere ADDRTYPE match dst-type LOCAL
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
DOCKER all -- anywhere !127.0.0.0/8 ADDRTYPE match dst-type LOCAL
Chain POSTROUTING (policy ACCEPT)
target prot opt source destination
MASQUERADE all -- ip-172-17-0-0.ec2.internal/16 anywhere
MASQUERADE all -- ip-10-8-1-0.ec2.internal/24 anywhere
Chain DOCKER (2 references)
target prot opt source destination
RETURN all -- anywhere anywhere
Явная проверка также говорит о его наличии:
$ sudo iptables -t nat -C POSTROUTING -s 10.8.1.0/24 -o eth0 -j MASQUERADE && echo ok
ok
Ubuntu имеет ufw установлен, но не активен:
$ sudo ufw status
Status: inactive
Вот дополнительная информация о системе:
$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 16.04.5 LTS
Release: 16.04
Codename: xenial
$ openvpn --version
OpenVPN 2.4.4 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Sep 26 2017
library versions: OpenSSL 1.0.2g 1 Mar 2016, LZO 2.08
$ route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 10.2.50.1 0.0.0.0 UG 0 0 0 eth0
10.2.50.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
10.8.1.0 10.8.1.2 255.255.255.0 UG 0 0 0 tun0
10.8.1.2 0.0.0.0 255.255.255.255 UH 0 0 0 tun0
172.17.0.0 0.0.0.0 255.255.0.0 U 0 0 0 docker0
Конфигурация сервера:
$ cat /etc/openvpn/server.conf | egrep -v '^#' | egrep -v '^$'
port 1194
proto udp
dev tun
ca ca.crt
cert VPN.crt
key VPN.key # This file should be kept secret
dh dh2048.pem
server 10.8.1.0 255.255.255.0
ifconfig-pool-persist ipp.txt
push "redirect-gateway def1 bypass-dhcp"
push "dhcp-option DNS 8.8.8.8"
keepalive 10 120
tls-auth ta.key 0 # This file is secret
compress lzo
user nobody
group nogroup
persist-key
persist-tun
status openvpn-status.log
verb 4
plugin openvpn-plugin-auth-pam.so openvpn
reneg-sec 43200
reneg-bytes 0
cipher AES-256-CBC
ncp-ciphers AES-256-GCM:AES-256-CBC:AES-128-GCM:AES-128-CBC:BF-CBC
crl-verify crl.pem
Конфигурация клиента:
client
dev tun
proto udp
remote <server IP> 1194
resolv-retry infinite
nobind
persist-key
persist-tun
remote-cert-tls server
key-direction 1
compress lzo
verb 3
auth-user-pass
auth-nocache
reneg-sec 43200
cipher AES-256-CBC
<ca>
-----BEGIN CERTIFICATE-----
# redacted
-----END CERTIFICATE-----
</cert>
<key>
-----BEGIN PRIVATE KEY-----
# redacted
-----END PRIVATE KEY-----
</key>
<tls-auth>
-----BEGIN OpenVPN Static key V1-----
# redacted
-----END OpenVPN Static key V1-----
</tls-auth>
Информация о системе: экземпляр EC2, созданный из ubuntu/images/hvm-ssd/ubuntu-xenial-16.04-amd64-server-20180814 образ.
Группы безопасности разрешают весь исходящий трафик и следующий входящий трафик:
Я читал об отключении Source/Destination Check. Не уверен, что это применимо к моему случаю, так как мне не нужно предоставлять доступ к сети AWS VPC, но я попробовал и это, и это не помогло.
Что меня больше всего озадачивает, так это то, что у нас уже есть рабочий VPN-сервер, настроенный аналогичным образом в другом регионе, но по какой-то причине я не могу заставить работать новый экземпляр. Так что я даже не уверен, что это специфично для AWS.
Может кто подскажет, где искать проблему?
Не уверен, в чем была причина, но я просто перезагрузил экземпляр, и проблема волшебным образом исчезла.
Перед этим я попытался отладить iptables (благодаря ответам на этот вопрос) и казалось, что пакеты никогда не доходили iptables все вместе (обратите внимание на нули в строках с правилами для ip-10-8-1-0.ec2.internal/24):
$ sudo iptables -t nat -L -v
Chain PREROUTING (policy ACCEPT 1249 packets, 93674 bytes)
pkts bytes target prot opt in out source destination
59 3938 DOCKER all -- any any anywhere anywhere ADDRTYPE match dst-type LOCAL
Chain INPUT (policy ACCEPT 2 packets, 140 bytes)
pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 923 packets, 58794 bytes)
pkts bytes target prot opt in out source destination
0 0 DOCKER all -- any any anywhere !127.0.0.0/8 ADDRTYPE match dst-type LOCAL
Chain POSTROUTING (policy ACCEPT 923 packets, 58794 bytes)
pkts bytes target prot opt in out source destination
29 1910 MASQUERADE all -- any !docker0 ip-172-17-0-0.ec2.internal/16 anywhere
0 0 LOG all -- any eth0 ip-10-8-1-0.ec2.internal/24 anywhere LOG level warning prefix "nat"
0 0 MASQUERADE all -- any eth0 ip-10-8-1-0.ec2.internal/24 anywhere
Chain DOCKER (2 references)
pkts bytes target prot opt in out source destination
0 0 RETURN all -- docker0 any anywhere anywhere
После перезагрузки пакеты успешно проходят:
$ sudo iptables -t nat -L -v
Chain PREROUTING (policy ACCEPT 35 packets, 2438 bytes)
pkts bytes target prot opt in out source destination
1 70 DOCKER all -- any any anywhere anywhere ADDRTYPE match dst-type LOCAL
Chain INPUT (policy ACCEPT 1 packets, 70 bytes)
pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 281 packets, 17695 bytes)
pkts bytes target prot opt in out source destination
0 0 DOCKER all -- any any anywhere !127.0.0.0/8 ADDRTYPE match dst-type LOCAL
Chain POSTROUTING (policy ACCEPT 283 packets, 17975 bytes)
pkts bytes target prot opt in out source destination
0 0 MASQUERADE all -- any !docker0 ip-172-17-0-0.ec2.internal/16 anywhere
32 2088 MASQUERADE all -- any eth0 ip-10-8-1-0.ec2.internal/24 anywhere
Chain DOCKER (2 references)
pkts bytes target prot opt in out source destination
0 0 RETURN all -- docker0 any anywhere anywhere
Я отмечаю, что на мой вопрос дан ответ, но я рад передать флаг правильного ответа любому, кто намекнет, почему это происходит.