OpenVPN для определенных IP, eth0 для всего остального

OpenVPN для определенных IP, eth0 для всего остального

Резюме: Я хотел бы подключиться к своему VPN и получить доступ к определенным серверам, но для всего остального трафика я хотел бы использовать свою обычную сеть.

Я настроил сервер OpenVPN на своем VPS, мой server.confфайл выглядит так:

port 1194
proto udp
dev tun
ca ca.crt
cert server.crt
key server.key  # This file should be kept secret
dh dh2048.pem
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
keepalive 10 120
comp-lzo
user nobody
group nogroup
persist-key
persist-tun
status openvpn-status.log
log         /var/log/openvpn.log
verb 4
push "route 10.132.0.0 255.255.0.0"

.ovpnДля настройки VPN-подключения я использую следующий файл:

client
dev tun
proto udp
remote <my.vpn.server.com> 1194
nobind
user nobody
group nogroup
persist-key
persist-tun
remote-cert-tls server
comp-lzo
verb 3
<ca>....</ca>
<cert>...</cert>
<key>...</key>

Наконец, в сетевом менеджере для VPN-подключения в разделе «Параметры IPv4» я обязательно установил «Метод» на «Только автоматические (VPN) адреса».

VPN подключается нормально, я могу получить доступ ко всем внутренним серверам, которые мне нужны (10.132.xx), однако я не могу получить доступ ни к чему другому (например, google.com). Я бы хотел, чтобы мои настройки eth0 использовались для всего, кроме IP-адресов 10.132.xx, которые я хотел бы направлять через VPN.

P.S. основываясь на других статьях, я пробовал использовать no-pullфайл .ovpn и добавлять routeтуда свои настройки, но безрезультатно.

ПРАВКА 1:

Результаты работы ip aи tracerouteпри подключении к VPN:

$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 08:00:27:dc:a6:ef brd ff:ff:ff:ff:ff:ff
    inet 10.0.2.15/24 brd 10.0.2.255 scope global dynamic eth0
       valid_lft 86320sec preferred_lft 86320sec
    inet6 fe80::f3d1:6eb3:e13e:d61b/64 scope link 
       valid_lft forever preferred_lft forever
15: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 100
    link/none 
    inet 10.8.0.6 peer 10.8.0.5/32 brd 10.8.0.6 scope global tun0
       valid_lft forever preferred_lft forever

$ traceroute google.com
google.com: Temporary failure in name resolution
Cannot handle "host" cmdline arg `google.com' on position 1 (argc 1)

ПРАВКА 2: Результатыip r

$ ip r
default via 10.8.0.5 dev tun0  proto static  metric 50 
default via 10.0.2.2 dev eth0  proto static  metric 100 
10.0.2.0/24 dev eth0  proto kernel  scope link  src 10.0.2.15  metric 100 
10.8.0.1 via 10.8.0.5 dev tun0  proto static  metric 50 
10.8.0.5 dev tun0  proto kernel  scope link  src 10.8.0.6  metric 50 
10.132.0.0/16 via 10.8.0.5 dev tun0  proto static  metric 50 
104.236.239.153 via 10.0.2.2 dev eth0  proto static  metric 100 
169.254.0.0/16 dev eth0  scope link  metric 1000 

решение1

"Используйте это подключение только для ресурсов в своей сети." флажок в nm-connection-editor управляет тем, должен ли NetworkManager добавлять маршрут по умолчанию через VPN. Если он установлен, как вы это сделали, через шлюз VPN будут проходить только пакеты, направленные в подсеть VPN, а система будет использовать существующий маршрут по умолчанию для других пунктов назначения.

Вы можете изменить эту же настройку из командной строки с помощью nmcli:

nmcli connection modify <VPN connection> ipv4.never-default yes

решение2

Мне удалось добиться желаемого эффекта, поэкспериментировав с клиентским GUI (Ubuntu NetworkManager). Мне пришлось убедиться, что флажок под IPv4 Settings -> Routesопцией «Использовать это подключение только для ресурсов в его сети» установлен:

«Использовать это соединение только для ресурсов в своей сети»

Я не совсем уверен, что мне нужно сделать в файле .ovpn, чтобы воспроизвести это.

Теперь моя таблица маршрутизации выглядит так:

$ sudo netstat -r -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
0.0.0.0         10.0.2.2        0.0.0.0         UG        0 0          0 eth0
10.0.2.0        0.0.0.0         255.255.255.0   U         0 0          0 eth0
10.8.0.1        10.8.0.5        255.255.255.255 UGH       0 0          0 tun0
10.8.0.5        0.0.0.0         255.255.255.255 UH        0 0          0 tun0
10.132.0.0      10.8.0.5        255.255.0.0     UG        0 0          0 tun0
104.236.239.153 10.0.2.2        255.255.255.255 UGH       0 0          0 eth0
169.254.0.0     0.0.0.0         255.255.0.0     U         0 0          0 eth0

Помните, что у меня был push "route 10.132.0.0 255.255.0.0"в моем server.confтак что это объясняет запись для 10.132.0.0и, таким образом, почему я теперь могу получить доступ к своим серверам, в то время как все остальное маршрутизируется за пределы VPN (т.е. запись 0.0.0.0)

Без проверки этого параметра в графическом интерфейсе моя таблица маршрутизации выглядела так:

$ sudo netstat -r -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
0.0.0.0         10.8.0.5        0.0.0.0         UG        0 0          0 tun0
0.0.0.0         10.0.2.2        0.0.0.0         UG        0 0          0 eth0
10.0.2.0        0.0.0.0         255.255.255.0   U         0 0          0 eth0
10.8.0.1        10.8.0.5        255.255.255.255 UGH       0 0          0 tun0
10.8.0.5        0.0.0.0         255.255.255.255 UH        0 0          0 tun0
10.132.0.0      10.8.0.5        255.255.0.0     UG        0 0          0 tun0
104.236.239.153 10.0.2.2        255.255.255.255 UGH       0 0          0 eth0
169.254.0.0     0.0.0.0         255.255.0.0     U         0 0          0 eth0

Полагаю, что первый 0.0.0.0вход (маршрут по умолчанию) все испортил.

решение3

Чтобы пояснить ответ jdmorei, вам нужен так называемый VPN с «разделенным туннелем» — на самом деле вы почти нашли решение, когда заявили: P.S. based on other articles I've tried using no-pull in the .ovpn file and adding in my route settings there but to no avail..

В вашем файле ovpn вам понадобится следующее:

route-nopull # Make sure not to pull the default routes
route 10.8.0.0 255.255.255.0 # Route the /24 of 10.8.0.0 across the VPN
route 192.168.2.2 255.255.255.255 # Route the /32 (single IP) across the VPN

Теперь самое главное, поскольку вы работаете в Windows, выдолжензапустите приложение openvpn от имени администратора. Если вы этого не сделаете, то увидите в журнале записи типа:

Sat Nov 13 11:31:05 2010 ROUTE: route addition failed using CreateIpForwardEntry
: Access denied.   [status=5 if_index=11]
The requested operation requires elevation. 
Sat Nov 13 11:31:05 2010 ERROR: Windows route add command failed [adaptive]: ret
urned error code 1
Sat Nov 13 11:31:05 2010 Initialization Sequence Completed

решение4

Я использую FreshTomato. Мне удалось перенаправить только 3 IP-адреса назначения на VPN.

Ниже представлена ​​пользовательская конфигурация OpenVPN:

allow-pull-fqdn
route-nopull
script-security 2
up /opt/openvpn-routes.sh

Затем сценарий, упомянутый выше:

root@router:/tmp/home/root# cat /opt/openvpn-routes.sh 
#!/bin/sh
ip route add 204.11.51.251/32  dev tun11 # www.linksysinfo.org
ip route add 201.54.48.99/32   dev tun11 # www12.senado.leg.br
ip route add 34.160.111.145/32 dev tun11 # ifconfig.me

Точка монтирования /opt была настроена в соответствии с инструкциями изhttps://github.com/Entware/Entware/wiki/Install-on-TomatoUSB-and-FreshTomato

Связанный контент