Назад | Перейти на главную страницу

OpenVPN: MULTI: неверный адрес источника от клиента, пакет потерян

У меня есть VPS (стабильный Debian) с одним сетевым интерфейсом и одним публичным IP-адресом, настроенным на нем. Я установил на этот VPS openvpn пакет, и я хотел настроить VPN-сервер. Я использовал этот HOWTO.

Вот файлы конфигурации.

Сервер:

# egrep -v "^#|^;|^$" /etc/openvpn/server-vpn.conf
local 151.80.57.162
port 11941
proto udp
dev tun
ca /etc/openvpn/certs/ca.crt
cert /etc/openvpn/certs/server-vpn.crt
key /etc/openvpn/certs/server-vpn.key
dh /etc/openvpn/certs/dh4096.pem
topology subnet
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
push "redirect-gateway def1"
push "dhcp-option DNS 208.67.222.222"
push "dhcp-option DNS 208.67.220.220"
keepalive 10 120
cipher AES-256-CBC
auth SHA512
keysize 256
comp-lzo
persist-key
persist-tun
status openvpn-status.log
verb 4

Клиент:

# egrep -v "^#|^;|^$" /etc/openvpn/client-vpn.conf
client
dev tun
proto udp
remote 151.80.57.162 11941
resolv-retry infinite
nobind
persist-key
persist-tun
ca /etc/openvpn/certs/ca.crt
cert /etc/openvpn/certs/client-vpn.crt
key /etc/openvpn/certs/client-vpn.key
remote-cert-tls server
cipher AES-256-CBC
auth SHA512
keysize 256
comp-lzo
verb 4
auth-nocache
script-security 2
up /etc/openvpn/update-resolv-conf.sh
down /etc/openvpn/update-resolv-conf.sh

Я также включил пересылку на сервере и добавил правило NAT:

# iptables -S FORWARD
-P FORWARD DROP
-A FORWARD -s 10.8.0.0/24 -i tun0 -o eth0 -j ACCEPT
-A FORWARD -d 10.8.0.0/24 -i eth0 -o tun0 -j ACCEPT

# iptables -S -t nat
-P PREROUTING ACCEPT
-P INPUT ACCEPT
-P OUTPUT ACCEPT
-P POSTROUTING ACCEPT
-A POSTROUTING -s 10.8.0.0/24 -o eth0 -j SNAT --to-source 151.80.57.162

# sysctl -a | grep -i net.ipv4.ip_forward
net.ipv4.ip_forward = 1

Порт VPN также открыт в цепочке INPUT.

Я могу пинговать сервер с клиента, а также клиент с сервера. Так что связь работает хорошо. Вот таблица маршрутизации на клиенте после установления туннеля:

$ ip route show
0.0.0.0/1 via 10.8.0.1 dev tun0 default via 192.168.1.1 dev eth0
10.8.0.0/24 dev tun0 proto kernel scope link src 10.8.0.4
128.0.0.0/1 via 10.8.0.1 dev tun0
151.80.57.162 via 192.168.1.1 dev eth0
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.150
192.168.10.0/24 dev br-lxc proto kernel scope link src 192.168.10.100

Вот интерфейсы eth0 и tun0 на клиенте:

$ ip addr show eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 3c:4a:92:00:4c:5b brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.150/24 brd 192.168.1.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::3e4a:92ff:fe00:4c5b/64 scope link
       valid_lft forever preferred_lft forever

$ ip addr show tun0
74: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 100
    link/none
    inet 10.8.0.4/24 brd 10.8.0.255 scope global tun0
       valid_lft forever preferred_lft forever
    inet6 fe80::dc57:9092:9cc2:abcc/64 scope link flags 800
       valid_lft forever preferred_lft forever

А еще на сервере есть маршруты и интерфейсы:

# ip route show
default via 151.80.57.1 dev eth0
10.8.0.0/24 dev tun0  proto kernel  scope link  src 10.8.0.1
151.80.57.1 dev eth0  scope link

# ip addr show eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether fa:16:3e:dd:db:03 brd ff:ff:ff:ff:ff:ff
    inet 151.80.57.162/32 brd 151.80.57.162 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::f816:3eff:fedd:db03/64 scope link
       valid_lft forever preferred_lft forever

# ip addr show tun0
60: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 100
    link/none
    inet 10.8.0.1/24 brd 10.8.0.255 scope global tun0
       valid_lft forever preferred_lft forever

Таким образом, соединение между клиентом и сервером может быть установлено, и похоже, что оно работает хорошо. Но когда я хочу отправить некоторый трафик через этот VPN-сервер, он работает только частично. Я имею в виду, что часть клиентского трафика успешно маршрутизируется через VPN, а часть - нет, и я не знаю почему.

Wireshark показывает что-то вроде этого (интерфейс tun0 на клиенте):

Думаю, именно поэтому страницы в FF не загружаются, но мой jabber-клиент работает хорошо, как вы можете видеть на той же картинке. DNS тоже работает. Я могу пинговать 8.8.8.8 и разрешать домены через VPN, но по некоторым причинам трафик WWW / MAIL (и, возможно, некоторые другие) не может пройти через VPN-сервер.

Просматривая журналы VPN-сервера (глагол 4), я вижу множество следующих сообщений:

Wed Nov 30 17:59:48 2016 us=146856 client-vpn/94.254.226.118:7669 MULTI: bad source address from client [192.168.1.150], packet dropped
Wed Nov 30 17:59:48 2016 us=421203 client-vpn/94.254.226.118:7669 MULTI: bad source address from client [192.168.1.150], packet dropped
Wed Nov 30 17:59:49 2016 us=10514 client-vpn/94.254.226.118:7669 MULTI: bad source address from client [192.168.1.150], packet dropped

У меня есть другие VPN-серверы, к которым я подключаюсь, но они не мои, и соединения работают без проблем, поэтому, вероятно, что-то не так с моим VPN-сервером. Я просто хочу подключиться к VPN, чтобы изменить свой IP-адрес при просмотре сети. Возникает вопрос: как заставить работать VPN?

Я знаю, в чем проблема. У меня был установлен SYNproxy на портах 80 и 443, поэтому механизм может защитить мой веб-сервер. К сожалению, я забыл указать -i eth0 в raw таблица iptables. Таким образом, весь трафик, который я отправлял через VPN и предназначался для портов, был просто помечен как INVALID, а затем отброшен в цепочке INPUT в таблице фильтров, вероятно, из-за другого MSS (требуется 1460).

Здесь вы можете увидеть пакет SYN и его порт, зарегистрированный в raw стол:

Dec 05 18:49:35 kernel: IN=tun0 OUT= MAC= SRC=10.8.0.10 DST=46.105.189.254 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=23425 DF PROTO=TCP SPT=61546 DPT=80 WINDOW=29200 RES=0x00 SYN URGP=

И этот SYN был заблокирован, поэтому он не получил SYN-ACK, и поэтому я получил этот странный наполовину рабочий VPN. Теперь все работает нормально.