Доступ к подсети за сервером openvpn

Question

У меня установлен сервер Ubuntu OpenVPN. Все работает просто отлично, VPN-клиенты могут успешно подключаться к VPN-серверу. Проблема в том, что я не могу подключиться к компьютерам за VPN-сервером

tcp dump на tun0 root @ gtway-sr-s:~ # tcpdump -i tun0

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun0, link-type RAW (Raw IP), capture size 65535 bytes
15:10:45.785732 IP 10.8.0.6 > 192.168.33.2: ICMP echo request, id 7, seq 48841, length 40
15:10:50.469529 IP 10.8.0.6 > 192.168.33.2: ICMP echo request, id 7, seq 48850, length 40

И это для em2 [192.168.33.2]

root@gtway-sr-s:~# tcpdump -i em2
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on em2, link-type EN10MB (Ethernet), capture size 65535 bytes
15:15:15.460870 ARP, Request who-has 192.168.33.2 tell 192.168.33.1, length 28
15:15:15.461025 ARP, Reply 192.168.33.2 is-at e4:1f:13:bb:0f:f2 (oui Unknown), length 46
15:15:15.464351 IP 192.168.33.1 > 192.168.33.2: ICMP echo request, id 7, seq 49287, length 40
15:15:15.464544 IP 192.168.33.2 > 192.168.33.1: ICMP echo reply, id 7, seq 49287, length 40
15:15:16.187506 IP 192.168.33.2.60143 > 229.111.112.12.3071: UDP, length 4
15:15:20.448006 IP 192.168.33.1 > 192.168.33.2: ICMP echo request, id 7, seq 49296, length 40
15:15:20.448207 IP 192.168.33.2 > 192.168.33.1: ICMP echo reply, id 7, seq 49296, length 40
15:15:21.491924 IP 192.168.33.2.60143 > 229.111.112.12.3071: UDP, length 4
15:15:25.450927 IP 192.168.33.1 > 192.168.33.2: ICMP echo request, id 7, seq 49304, length 40
15:15:25.451132 IP 192.168.33.2 > 192.168.33.1: ICMP echo reply, id 7, seq 49304, length 40
15:15:26.823644 IP 192.168.33.2.60143 > 229.111.112.12.3071: UDP, length 4
15:15:30.459822 IP 192.168.33.1 > 192.168.33.2: ICMP echo request, id 7, seq 49315, length 40
15:15:30.460016 IP 192.168.33.2 > 192.168.33.1: ICMP echo reply, id 7, seq 49315, length 40
15:15:32.148672 IP 192.168.33.2.60143 > 229.111.112.12.3071: UDP, length 4
15:15:35.143425 ARP, Request who-has 192.168.33.1 (b0:83:fe:e3:2e:1a (oui Unknown)) tell 192.168.33.2, length 46
15:15:35.143431 ARP, Reply 192.168.33.1 is-at b0:83:fe:e3:2e:1a (oui Unknown), length 28
15:15:35.453679 IP 192.168.33.1 > 192.168.33.2: ICMP echo request, id 7, seq 49324, length 40
15:15:35.453861 IP 192.168.33.2 > 192.168.33.1: ICMP echo reply, id 7, seq 49324, length 40
15:15:37.485259 IP 192.168.33.2.60143 > 229.111.112.12.3071: UDP, length 4
15:15:40.455035 IP 192.168.33.1 > 192.168.33.2: ICMP echo request, id 7, seq 49333, length 40
15:15:40.455220 IP 192.168.33.2 > 192.168.33.1: ICMP echo reply, id 7, seq 49333, length 40
15:15:40.468865 ARP, Request who-has 192.168.33.2 tell 192.168.33.1, length 28
15:15:40.469000 ARP, Reply 192.168.33.2 is-at e4:1f:13:bb:0f:f2 (oui Unknown), length 46
15:15:42.827137 IP 192.168.33.2.60143 > 229.111.112.12.3071: UDP, length 4
15:15:45.461731 IP 192.168.33.1 > 192.168.33.2: ICMP echo request, id 7, seq 49343, length 40
15:15:45.461919 IP 192.168.33.2 > 192.168.33.1: ICMP echo reply, id 7, seq 49343, length 40

Answer 1

Измените файл конфигурации сервера, добавив в него следующую строку:

  push "route 192.168.73.0 255.255.255.0"

где 192.168.73.0/24 - локальная сеть за сервером. Замените на то, что вы используете. Двойные кавычки должны быть сохранены, а не выброшены.

УВЕДОМЛЕНИЕ:

Вышеперечисленное завершится сбоем, если локальная сеть за сервером и локальная сеть, к которой принадлежит клиент, в некоторой степени перекрываются, и особенно если они используют одну и ту же подсеть: в приведенном выше примере произойдет сбой, если как клиентская, так и серверная локальная сеть будут иметь 192.168. 73,0/255. Это проблема, потому что большинство локальных сетей с автоматической настройкой имеют 192.168.1.0/24 или 192.168.0.0/24, так что есть много шансов найти коллизию.

Это причина, по которой я настроил локальную сеть дома как 192.168.73.0/24. Переключение локальной сети в необычную подсеть - единственное возможное средство от такого столкновения.

РЕДАКТИРОВАТЬ:

В ответ на ваш комментарий:

1. коллизия происходит не между локальной сетью за сервером и IP-номерами, передаваемыми клиентам openvpn, а между двумя локальными сетями: ваш клиент должен иметь в своем интерфейсе ethernet/wifi IP-номер, который не должен конфликтовать с удаленной локальной сетью , Забудьте о подсети для клиентов openvpn.

2. Как только вышеперечисленное было настроено, остается проверить, может ли сервер передавать пакеты с виртуального интерфейса (я готов поспорить, что в вашем случае это tun0 , а не tap0 , я прав) на обычный интерфейс сервера ( Могу поспорить, что это eth0, а не br0). Это может произойти по двум причинам:

   а. Вы не разрешили пересылку IPv4. Как судо,

    echo 1  /proc/sys/net/ipv4/ip_forward
   

   позаботится об этом.

   б. У вас есть брандмауэр, который блокирует пересылку пакетов.

   sudo iptables -F 
   

   очистит ваши правила брандмауэра.

3. Наконец, вы должны помнить использовать MASQUERADE, как показано ниже:

      iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -d 192.168.33.0/24 -j MASQUERADE