Нет ошибок, нет отброшенных пакетов, пинги достигают клиентов, tcpdump показывает, что пакеты перемещаются, все остальное никогда не достигает хостов LAN (или клиентов OpenVPN).
После попытки устранить все возможные факторы, мешающие работе, я перенастроил свою виртуальную машину, чтобы использовать мосты вместо MacVTap. Теперь доступ к клиентам LAN работает как положено. Надеюсь, это не окончательный ответ (я бы хотел сохранить MacVTap).
Раньше я немного занимался виртуальными машинами и сетями, но такое поведение, как описано ниже, для меня совершенно ново.
Редактировать: Что меня больше всего поражает, так это то, что ответы (например, DNS-запрос) направляются обратно клиенту (я добавил его tcpdump), но dig все еще работает с таймаутом.
Я ломаю голову над этим уже несколько дней, и я не могу найти ничего на interwebz (возможно, слабый поисковый фу), поэтому я подумал, что пришло время для вас, ServerFaulters.
Задача (по сути, просто): настройте сервер OpenVPN, направьте трафик в локальную сеть за ним.
Проблема: Ping успешно, "все остальное" нет. На хосте работает DNS-сервер, а также OpenSSH-сервер, оба из которых недоступны.
Я думал, что может быть маскировка / NAT вовлечены, но виноват вовсе не в этом.
На самом деле, я думаю, что сейчас я слишком глуп. Так что, пожалуйста, помогите отчаянному парню (и не стесняйтесь спрашивать даже более подробную информацию).
VPN-сервер и Хост виртуальные машины работают на машине VPN-клиент напрямую связан с. Обе виртуальные машины могут видеть друг друга, политики iptables настроены на ACCEPT на всех хостах.
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
Подключение OpenVPN (выдержки)
$ 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
Как вы можете видеть ниже, успешный пинг от VPN-клиента к хосту. (Пинги от хоста к VPN-клиенту работают одинаково хорошо, но я их здесь пропустил)
Это было сделано без каких-либо правил 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
Опять же, никаких правил 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
редактировать: Время ожидания соединения истекло, но есть ответ, который можно увидеть в 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)
Попробуйте начать с этих правил в брандмауэре:
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
Он должен обеспечивать полную связь между клиентами LAN и VPN.