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.
PS на основе других статей, которые я пробовал использовать no-pull в файле .ovpn и добавив туда настроек моего маршрута , но безрезультатно.
РЕДАКТИРОВАТЬ 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
Am reușit să obțin efectul dorit jucându-mă cu GUI-ul clientului (Ubuntu NetworkManager). A trebuit să mă asigur că a fost bifată caseta de selectare din Setări IPv4 -> Rute pentru „Utilizați această conexiune numai pentru resurse din rețeaua sa”:
Nu sunt pe deplin sigur ce ar trebui să fac în fișierul .ovpn pentru a replica acest lucru.
Tabelul meu de rutare arată acum așa:
$ 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
Amintiți-vă că am avut push "ruta 10.132.0.0 255.255.0.0" în server.conf , astfel încât se explică intrarea pentru 10.132.0.0 și, de aceea, acum pot să accesez serverele mele în timp ce orice altceva este direcționat în afara VPN (adică 0.0.0.0 intrare)
Fără ca această setare să fie verificată în interfața grafică, tabelul meu de rutare arăta așa:
$ 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
Presupun că prima 0.0.0.0 intrare (ruta implicită) încurca totul.
dacă serverul dvs. este / 24 ( 10.8.0.X )
server 10.8.0.0 255.255.255.0
și ruta pentru clienții dvs. este / 16 ( 10.132.XX )
împingeți "ruta 10.132.0.0 255.255.0.0"
Poate că nu ar fi un conflict?
Pentru a explica răspunsul lui jdmorei, aveți nevoie de ceea ce se numește un VPN „divizat în tunel” - de fapt aproape ați avut soluția când a declarat: PS pe baza altor articole, am încercat să folosesc no-pull în fișierul .ovpn și să adaug în setările rutei mele, dar fără rezultat. .
Veți dori următoarele în fișierul 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
Acum cheia este că, din moment ce rulați Windows, trebuie să să executați aplicația openvpn ca administrator. Dacă nu, veți vedea intrări în jurnal, cum ar fi:
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
Флажок "Использовать это соединение только для ресурсов своей сети" в nm-connection-редакторе контролирует, должен ли NetworkManager добавлять маршрут по умолчанию через VPN. Если она отмечена, как и вы, то только пакеты, направленные в подсеть VPN, будут проходить через VPN шлюз, и система будет использовать существующий маршрут по умолчанию для других назначений.
Вы можете изменить ту же самую настройку из командной строки, используя nmcli:
nmcli connection modify <VPN connection> ipv4.never-default yes