В настоящее время у меня есть сервер openvpn и настройка клиента с роутингом (не мостом)
Когда я пытаюсь выполнить пинг с моего клиента на IP-адрес сервера, он работает нормально. Но когда я пытаюсь пропинговать остальные узлы подсети за сервером openvpn, это не работает. Может ли кто-нибудь заметить что-то явно неправильное в моей настройке. (сервер openvpn находится на 10.10.145.181, а хост - на IP-адресе 10.10.146.8. Они находятся в двух разных подсетях. Я могу пинговать 10.10.146.8 из 10.10.145.181 напрямую, подключившись к этому хосту. Только когда я иду через VPN, он делает не работает.)
Насколько я понимаю, ping-трафик попадает на vpn-сервер на интерфейсе tun0, но тогда vpn-сервер не пересылает его через eth0 на соответствующий хост, и, следовательно, pinged-хост не видит никакого трафика, и пакет отбрасывается. Но что могло быть причиной этого? Есть ли в openvpn настройка для перенаправления трафика с tun0 на eth0?
Вот что я наблюдаю ...
На клиентском хосте openvpn:
> ping 10.10.146.8
PING 10.10.146.8 (10.10.146.8) 56(84) bytes of data.
<no further output>
На хосте openvpn server:
> sudo tcpdump -i tun0 'icmp[icmptype] = icmp-echo or icmp[icmptype] = icmp-echoreply'
00:34:32.624639 IP 10.10.0.6 > 10.10.146.8: ICMP echo request, id 1644, seq 1863, length 64
00:34:33.634564 IP 10.10.0.6 > 10.10.146.8: ICMP echo request, id 1644, seq 1864, length 64
00:34:34.640753 IP 10.10.0.6 > 10.10.146.8: ICMP echo request, id 1644, seq 1865, length 64
00:34:35.648922 IP 10.10.0.6 > 10.10.146.8: ICMP echo request, id 1644, seq 1866, length 64
00:34:36.659062 IP 10.10.0.6 > 10.10.146.8: ICMP echo request, id 1644, seq 1867, length 64
00:34:37.665402 IP 10.10.0.6 > 10.10.146.8: ICMP echo request, id 1644, seq 1868, length 64
00:34:38.673295 IP 10.10.0.6 > 10.10.146.8: ICMP echo request, id 1644, seq 1869, length 64
00:34:39.685336 IP 10.10.0.6 > 10.10.146.8: ICMP echo request, id 1644, seq 1870, length 64
00:34:40.687703 IP 10.10.0.6 > 10.10.146.8: ICMP echo request, id 1644, seq 1871, length 64
00:34:41.695766 IP 10.10.0.6 > 10.10.146.8: ICMP echo request, id 1644, seq 1872, length 64
> sudo tcpdump -i eth0 'icmp[icmptype] = icmp-echo or icmp[icmptype] = icmp-echoreply'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
04:14:48.583673 IP 10.10.0.6 > 10.10.146.8: ICMP echo request, id 4807, seq 442, length 64
04:14:49.592908 IP 10.10.0.6 > 10.10.146.8: ICMP echo request, id 4807, seq 443, length 64
04:14:50.600010 IP 10.10.0.6 > 10.10.146.8: ICMP echo request, id 4807, seq 444, length 64
04:14:51.616401 IP 10.10.0.6 > 10.10.146.8: ICMP echo request, id 4807, seq 445, length 64
На хосте в подсети, которую я пытаюсь пропинговать (10.10.146.8):
> sudo tcpdump -i eth0 'icmp[icmptype] = icmp-echo or icmp[icmptype] = icmp-echoreply'
sudo: unable to resolve host ip-10-10-146-8
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
<no further output>
Системный журнал (журнал openvpn) говорит:
Jul 8 00:36:25 ip-10-10-145-181 ovpn-server[1513]: xyz/<ip_address>:35315 UDPv4 READ [133] from [AF_INET]<ip_address>:35315: P_DATA_V1 kid=0 DATA len=132
Jul 8 00:36:25 ip-10-10-145-181 ovpn-server[1513]: xyz/<ip_address>:35315 TUN WRITE [84]
netstat на клиенте openvpn:
10.10.0.1 10.10.0.5 255.255.255.255 UGH 0 0 0 tun0
10.10.0.5 0.0.0.0 255.255.255.255 UH 0 0 0 tun0
10.10.146.0 10.10.0.5 255.255.255.0 UG 0 0 0 tun0
netstat на сервере openvpn:
10.10.0.0 10.10.0.2 255.255.255.0 UG 0 0 0 tun0
10.10.0.2 0.0.0.0 255.255.255.255 UH 0 0 0 tun0
10.10.145.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
У меня есть инструкция в конфигурации сервера openvpn для маршрутизации трафика со стороны клиента, и я вижу, что это происходит.
push "route 10.10.146.0 255.255.255.0"
Дополнительная информация к вопросу Андрея
> echo "sysctl -a | grep 'forwarding = 1'" | sudo -s
error: permission denied on key 'vm.compact_memory'
error: permission denied on key 'net.ipv4.route.flush'
net.ipv4.conf.all.forwarding = 1
net.ipv4.conf.default.forwarding = 1
net.ipv4.conf.lo.forwarding = 1
net.ipv4.conf.eth0.forwarding = 1
net.ipv4.conf.tun0.forwarding = 1
error: permission denied on key 'net.ipv6.route.flush'
> sudo iptables -L INPUT
Chain INPUT (policy ACCEPT)
target prot opt source destination
> sudo iptables -L FORWARD
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Обновление: на самом деле теперь я вижу трафик на eth0 на сервере, но этот трафик не попадает в сеть и не принимается другим хостом. Думаю, это проблема Amazon VPC.
Хорошо, я понял это после нескольких часов расследования.
Проблема в настройке пересылки. Пакеты, перенаправленные на порт eth0, не имеют правильного IP-адреса источника хоста в сети. IP-адрес от VPN.
05:07:43.991961 IP 10.8.0.6 > 10.10.146.8: ICMP echo request, id 3497, seq 499, length 64
Вы можете переключить это, включив эквивалент NAT (на маршрутизаторах) в ОС Linux:
iptables -t nat -A POSTROUTING -o <eth0 or whatever else> -j MASQUERADE
Это устранило проблему для меня.
Эта проблема может возникнуть, если шлюз по умолчанию для хостов в локальной сети не является сервером OpenVPN. В таком случае хостам необходим статический маршрут для адресов VPN, чтобы ответы отправлялись на сервер VPN, а не на шлюз по умолчанию.
На хостах LAN проверьте маршруты (route print для Windows, route -n для Linux, ǹetstat -rn для Mac).
Я нашел эту ветку через Google, и спасибо, что эта информация оказалась полезной. У меня точно такая же проблема, и эта информация ЧАСТИЧНО ее решила.
Маскарад, и это сработало. Но для моей цели этого недостаточно, и для меня это не решение и не окончательный ответ, я все еще пытаюсь отправить его БЕЗ маскарадинга. Для моей цели, получить одно соединение НЕ ДОСТАТОЧНО. Потому что мне нужен исходный IP для целей идентификации и контроля доступа. Маскарадинг подключил его, но слепо принял. Соединение всегда создается с одного ЛОЖНОГО IP-адреса.
У меня есть SQL-сервер, который должен принимать / отклонять соединения в зависимости от IP-адреса источника после прохождения через VPN. Также желательно вести журнал доступа к IP, чтобы отслеживать ошибки или защищаться от взлома.
Все еще не понимаю, почему пересылка в этой конечной точке VPN не произойдет, если не замаскирована. Подозрение, что причиной является локальный брандмауэр или проблема безопасности.
Пожалуйста, поделитесь своим опытом или предложениями, пока вы путешествуете по этой теме. Спасибо.