Назад | Перейти на главную страницу

Получение клиента openvpn для перенаправления всего трафика через сервер

Я пытаюсь настроить сервер и клиент openvpn, при этом весь клиентский трафик маршрутизируется через сервер. В настоящее время я могу получить доступ к серверу через клиента, но когда я включаю 'push "redirect-gateway def1"' на сервере, клиент теряет всякую возможность подключиться к Интернету, vpn или как-то иначе. Кроме того, он больше не может подключаться к серверу, хотя подключение к локальной сети все еще в порядке. Мой файл конфигурации сервера:

local ***.***

port 1194

proto tcp

dev tun

ca ca.crt
cert server.crt
key server.key

dh dh2048.pem

server 10.8.0.0 255.255.255.0

ifconfig-pool-persist ipp.txt

push "redirect-gateway local def1"

keepalive 10 120

comp-lzo

persist-key
persist-tun

status openvpn-status.log

verb 3

а вот и клиент:

client

dev tun

proto tcp

remote ***.*** 1194

resolv-retry infinite

nobind

persist-key
persist-tun

ca ca.crt
cert laptop.crt
key laptop.key

ns-cert-type server

comp-lzo

verb 3

На сервере я включил ip forwarding и включил маршрутизацию через iptables:

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE

но клиент по-прежнему не может подключиться ни к чему в VPN или в Интернете.

Для справки, соответствующий раздел HOWTO Вот, хотя я подозреваю, что вы за этим следили.

Первое, что я попробую, это удалить «локальный», то есть команда должна быть

push "redirect-gateway def1"

и нет

push "redirect-gateway local def1"

Локальный флаг работает, только если все ваши клиенты находятся в одной подсети.

Еще пара вещей, о которых следует знать, - это то, что трафик DNS направляется через vpn, поэтому вы не сможете разрешать адреса, если не разобрались с этим. DHCP также может быть перенаправлен, хотя в вашем случае этого не должно происходить, поскольку вы используете маршрутизируемый, а не мостовой VPN, но, возможно, все равно стоит проверить.

Если вы «проталкиваете» новый шлюз клиенту, вам также необходимо протолкнуть некоторые маршруты, в частности, маршрут к подсети, в которой находится этот шлюз. Это даст вам доступ в Интернет через VPN. Если сеть, в которой находится шлюз, отличается от той, в которой находится VPN-сервер, вам также потребуются дополнительные маршруты, чтобы клиент мог получить доступ к этим другим сетям. Кроме того, вы можете также отправить DNS-серверы клиенту, потому что в противном случае клиент не сможет разрешить имена ни одной из целей в сети, к которой он теперь подключен.

Вот выдержка из нашего файла конфигурации сервера OpenVPN:

# Push route to client to bind it to our local
# virtual endpoint.
#
push "route 10.180.0.1 255.255.255.255"

# Push any routes the client needs to get in
# to the local network.
#
push "route 10.171.0.0 255.255.0.0"
push "route 10.172.0.0 255.255.0.0"
push "route 10.173.0.0 255.255.0.0"
push "route 10.174.0.0 255.255.0.0"
push "route 10.175.0.0 255.255.0.0"
push "route 10.176.0.0 255.255.0.0"
push "route 10.177.0.0 255.255.0.0"
push "route 10.181.0.0 255.255.0.0"
push "route 10.182.0.0 255.255.0.0"
push "route 192.168.61.0 255.255.255.0"

# Push DHCP options to Windows clients.
#
push "dhcp-option DOMAIN our-internal-domain.com"
push "dhcp-option DNS 10.a.b.c"
push "dhcp-option WINS 10.b.c.d"

Все это внутренние сети, и мы даже не запускаем новый шлюз (поскольку большинство наших пользователей подключаются издалека, им лучше выходить в Интернет через свой шлюз по умолчанию, и мы не фанаты контроля).

Собственно проблема заключалась в том, что NAT был настроен неправильно. Исправлено, и теперь vpn работает.