OpenVPN: MULTI: endereço de origem inválido do cliente, pacote descartado

1

Eu tenho um VPS (Debian estável) com uma interface de rede e um endereço IP público configurado nele. Eu instalei nesse VPS o pacote openvpn e queria configurar um servidor VPN. Eu estava usando este HOWTO .

Aqui estão os arquivos de configuração.

Servidor:

# 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

Cliente:

# 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

Também ativei o encaminhamento no servidor e adicionei a regra 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

A porta VPN também é aberta na cadeia INPUT.

Eu sou capaz de fazer ping do servidor a partir do cliente e também do cliente a partir do servidor. Então a conexão funciona bem. Aqui está a tabela de roteamento no cliente depois de estabelecer o túnel:

$ 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

Aqui estão as interfaces eth0 e tun0 no cliente:

$ 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

E aqui também estão rotas e interfaces no servidor:

# 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

Assim, a conexão entre o cliente e o servidor pode ser estabelecida e parece que funciona bem. Mas quando eu quero enviar algum tráfego através deste servidor VPN, ele funciona apenas parcialmente. Quero dizer, parte do tráfego do cliente é roteado com sucesso através da VPN, mas alguns não, e eu não sei o porquê.

O Wireshark mostra algo assim (a interface tun0 no cliente):

E eu acho que é por isso que as páginas no FF não são carregadas, mas meu cliente do jabber funciona bem, como você pode ver na mesma imagem. O DNS também funciona. Eu posso executar ping 8.8.8.8 e resolver domínios através da VPN, mas por algum motivo o tráfego WWW / MAIL (e provavelmente alguns outros também) não pode passar pelo servidor VPN.

Olhando para os registros do servidor VPN (verbo 4), posso ver muitas das seguintes mensagens:

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

Eu tenho outros servidores VPN aos quais me conecto, mas eles não são meus e as conexões funcionam sem problemas, então, algo está errado, provavelmente com o meu servidor VPN. Eu só quero ligar para a VPN, a fim de alterar o meu próprio endereço IP ao navegar na net. Então a questão é: como fazer a VPN funcionar?

    
por Mikhail Morfikov 30.11.2016 / 18:25

1 resposta

0

Eu sei onde estava o problema. Eu tinha SYNproxy definido nas portas 80 e 443, então o mecanismo te pode proteger meu servidor web. Infelizmente esqueci de especificar -i eth0 na tabela raw do iptables. Assim, todo o tráfego que eu estava enviando através da VPN e destinado às portas era simplesmente marcado como INVALID e depois descartado na cadeia INPUT na tabela de filtros, provavelmente por causa de diferentes MSS (necessários 1460).

Aqui você pode ver o pacote SYN e sua porta registrada na tabela 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=

E este SYN foi bloqueado, então é por isso que ele não recebeu o SYN-ACK, e é por isso que eu tenho essa estranha VPN de meio-trabalho. Agora tudo funciona bem.

    
por 05.12.2016 / 19:08