OpenVPN - VM-Setup com MacVTap, ICMP echo funciona, TCP / UPD não

1

Currículo curto

Nenhum erro, nenhum pacote descartado, pings chegam aos clientes, tcpdump mostra pacotes viajando, todo o resto nunca alcança os hosts LAN (ou clientes OpenVPN).

Editar

Depois de tentar eliminar todos os possíveis fatores disruptivos, eu reconfigurei minha configuração de VM para usar pontes em vez de MacVTap . Agora o acesso a clientes de rede local funciona conforme o esperado. Espero que esta não seja a resposta final (gostaria de manter o MacVTap).

Já fiz um pouco de trabalho em VMs e redes antes, mas esse comportamento, conforme descrito abaixo, é completamente novo para mim.

Editar: O que mais me impressiona é que as respostas (por exemplo, a consulta DNS) são roteadas de volta para o cliente (adicionei um tcpdump disso), mas a dig ainda corre para um tempo limite.

Eu tenho coçado a cabeça sobre isso há alguns dias e não consigo encontrar nada sobre o interwebz (talvez fraco search-fu), então eu pensei que era hora de você ServerFaulters lá fora.

Tarefa (essencialmente fácil): Configure um servidor OpenVPN, direcione o tráfego para a LAN por trás dele.

Problema : Pings são bem-sucedidos, "tudo mais" não. No host há um servidor DNS em execução, bem como um OpenSSH-Server, ambos os quais não podem ser alcançados.

Eu pensei que poderia haver masquerading / NATing envolvido, mas isso não foi o culpado.

Na verdade, acho que sou muito idiota agora. Então, por favor, ajude um cara desesperado (e não hesite em pedir ainda mais detalhes).

Configuração

VPN-Server e Host são VMs em execução em um Machine VPN-Client conectado diretamente a. Ambas as VMs podem ver uma à outra, as políticas do iptables estão configuradas para ACCEPT em todos os hosts.

OpenVPN-Server

eth0    10.0.0.3
tun0:1  172.16.0.3
tun0    10.8.0.1

# cat /proc/sys/net/ipv4/ip_forward
1

# lsmod
xt_conntrack           12681  3 
iptable_filter         12536  1 
ipt_MASQUERADE         12594  3 
iptable_nat            12646  1 
nf_conntrack_ipv4      18499  4 
nf_defrag_ipv4         12483  1 nf_conntrack_ipv4
nf_nat_ipv4            12912  1 iptable_nat
nf_nat                 22379  3 ipt_MASQUERADE,nf_nat_ipv4,iptable_nat
nf_conntrack           70753  6 ipt_MASQUERADE,nf_nat,nf_nat_ipv4,xt_conntrack,iptable_nat,nf_conntrack_ipv4
ip_tables              21914  2 iptable_filter,iptable_nat
x_tables               23015  4 ip_tables,ipt_MASQUERADE,xt_conntrack,iptable_filter
[…]

/etc/openvpn/server.conf

port 1194
proto udp
dev tun
server 10.8.0.0 255.255.255.0
push "route 10.0.0.0 255.255.255.0"
topology subnet # is this actually needed?

VPN-Client

eth0 172.16.0.100
tun0 10.8.0.4

$ ip route
10.0.0.0/24 via 10.8.0.1 dev tun0 
10.8.0.0/24 dev tun0  proto kernel  scope link  src 10.8.0.4 
172.16.0.0/24 dev eth0  proto kernel  scope link  src 172.16.0.100

Conexão OpenVPN (trechos)

$ sudo openvpn --config vpn.ovpn
…
UDPv4 link remote: [AF_INET]172.16.0.3:1194
TLS: Initial packet from [AF_INET]172.16.0.3:1194, sid=b636ac88 2ef4c575
[…] Peer Connection Initiated with [AF_INET]172.16.0.3:1194
SENT CONTROL […]: 'PUSH_REQUEST' (status=1)
PUSH: Received control message: 'PUSH_REPLY,route 10.0.0.0 255.255.255.0,route-gateway 10.8.0.1,topology subnet,ping 10,ping-restart 120,ifconfig 10.8.0.4 255.255.255.0'
/sbin/ip link set dev tun0 up mtu 1500
/sbin/ip addr add dev tun0 10.8.0.4/24 broadcast 10.8.0.255
/sbin/ip route add 10.0.0.0/24 via 10.8.0.1

Anfitrião

eth0 10.0.0.2

$ ip route
10.0.0.0/24 dev eth0  proto kernel  scope link  src 10.0.0.2 
10.8.0.0/24 via 10.0.0.3 dev eth0

Eco ICMP

Como você pode ver abaixo, obtém sucesso do VPN-Client para o Host. (Pings from Host para VPN-Client funcionam igualmente bem, mas eu os omiti aqui)

Isso foi feito sem regras de iptables.

VPN-Client

$ ping -c1 10.0.0.2
PING 10.0.0.2 (10.0.0.2) 56(84) bytes of data.
64 bytes from 10.0.0.2: icmp_seq=1 ttl=63 time=1.30 ms

--- 10.0.0.2 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 1.303/1.303/1.303/0.000 ms

OpenVPN-Server

tcpdump -i tun0
11:01:25.787428 IP 10.8.0.4 > 10.0.0.2: ICMP echo request, id 4209, seq 1, length 64
11:01:25.787899 IP 10.0.0.2 > 10.8.0.4: ICMP echo reply, id 4209, seq 1, length 64

Anfitrião

# tcpdump net 10.8.0.0/24
11:01:25.797640 IP 10.8.0.4 > 10.0.0.2: ICMP echo request, id 4209, seq 1, length 64
11:01:25.797682 IP 10.0.0.2 > 10.8.0.4: ICMP echo reply, id 4209, seq 1, length 64

Consulta DNS

Mais uma vez, não há regras de iptables.

VPN-Client

$ dig @10.0.0.2 serverfault.com

; <<>> DiG 9.9.3-rpz2+rl.13214.22-P2-Debian-1:9.9.3.dfsg.P2-4 <<>> @10.0.0.2 serverfault.com
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached

Editar : A conexão atinge o tempo limite, mas há uma resposta que pode ser vista no tcpdump:

# tcpdump -i tun0
14:26:26.609399 IP vpnclient.56553 > 10.0.0.2.domain: 44738+ [1au] A? serverfault.com. (44)
14:26:26.738504 IP 10.0.0.2.domain > vpnclient.56553: 44738$ 1/0/0 A 198.252.206.16 (49)

OpenVPN-Server

# tcpdump -i tun0
10:03:52.077784 IP 10.8.0.4.58792 > 10.0.0.2.domain: 61705+ [1au] A? serverfault.com. (44)
10:03:52.092420 IP 10.0.0.2.domain > 10.8.0.4.58792: 61705$ 1/0/0 A 198.252.206.16 (49)

Anfitrião

# tcpdump net 10.8.0.0/24
10:03:57.061048 IP 10.8.0.4.58792 > 10.0.0.2.domain: 61705+ [1au] A? serverfault.com. (44)
10:03:57.075223 IP 10.0.0.2.domain > 10.8.0.4.58792: 61705$ 1/0/0 A 198.252.206.16 (49)
    
por Alex 11.12.2013 / 12:11

1 resposta

0

Tente começar com estas regras no firewall:

iptables -A FORWARD -i tun0 -o eth0 -s 10.8.0.0/24 -j ACCEPT
iptables -A FORWARD -i eth0 -o tun0 -s 10.0.0.0/24 -j ACCEPT

Deve permitir a comunicação completa entre clientes de LAN e VPN.

    
por 11.12.2013 / 14:13