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.
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).
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).
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.
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?
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
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
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.
$ 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
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
# 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
Mais uma vez, não há regras de iptables.
$ 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)
# 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)
# 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)
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.