Zusammenfassung: Ich möchte eine Verbindung zu meinem VPN herstellen und auf bestimmte Server zugreifen, für den übrigen Datenverkehr möchte ich jedoch mein normales Netzwerk verwenden.
Ich habe einen OpenVPN-Server auf meinem VPS eingerichtet, meine server.conf
Datei sieht folgendermaßen aus:
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"
Ich verwende die folgende .ovpn
Datei, um die VPN-Verbindung einzurichten:
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>
Schließlich habe ich im Netzwerk-Manager für die VPN-Verbindung unter IPv4-Einstellungen darauf geachtet, die „Methode“ auf „Nur automatische (VPN-)Adressen“ einzustellen.
Die VPN-Verbindung funktioniert einwandfrei, ich kann auf alle internen Server zugreifen, die ich brauche (10.132.xx), aber auf nichts anderes (wie google.com). Ich möchte, dass meine eth0-Einstellungen für alles verwendet werden, außer für die 10.132.xx-IPs, die ich über das VPN leiten möchte.
PS: Basierend auf anderen Artikeln habe ich versucht, no-pull
die OVPN-Datei zu verwenden und dort meine Einstellungen hinzuzufügen, route
aber ohne Erfolg.
BEARBEITEN 1:
Ergebnisse beim Ausführen ip a
und traceroute
während der Verbindung mit 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)
BEARBEITEN 2: Ergebnisse vonip 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
Antwort1
Der "Verwenden Sie diese Verbindung nur für Ressourcen in ihrem NetzwerkDas Kontrollkästchen " im nm-connection-editor steuert, ob NetworkManager eine Standardroute durch das VPN hinzufügen soll. Wenn es wie von Ihnen aktiviert ist, werden nur an das VPN-Subnetz gerichtete Pakete durch das VPN-Gateway geleitet und das System verwendet die vorhandene Standardroute für andere Ziele.
Sie können die gleiche Einstellung über die Befehlszeile mit nmcli ändern:
nmcli connection modify <VPN connection> ipv4.never-default yes
Antwort2
Ich habe es geschafft, den gewünschten Effekt zu erzielen, indem ich mit der Client-GUI (Ubuntu NetworkManager) herumgespielt habe. Ich musste sicherstellen, dass das Kontrollkästchen unter IPv4 Settings -> Routes
„Diese Verbindung nur für Ressourcen in ihrem Netzwerk verwenden“ aktiviert war:
Ich bin nicht ganz sicher, was ich in der OVPN-Datei tun müsste, um dies zu replizieren.
Meine Routingtabelle sieht jetzt folgendermaßen aus:
$ 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"
Denken Sie daran, dass ich das in meinem hatte, server.conf
das erklärt also den Eintrag 10.132.0.0
und damit, warum ich jetzt auf meine Server zugreifen kann, während alles andere außerhalb des VPN geroutet wird (also der 0.0.0.0
Eintrag).
Ohne diese Einstellung in der GUI sah meine Routing-Tabelle folgendermaßen aus:
$ 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
Ich vermute, dass der erste 0.0.0.0
Eintrag (Standardroute) alles durcheinander gebracht hat.
Antwort3
Um die Antwort von jdmorei näher auszuführen: Sie benötigen ein sogenanntes „Split Tunnel“-VPN – Sie hatten die Lösung eigentlich fast, als Sie sagten: 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.
.
Folgendes sollte in Ihrer OVPN-Datei enthalten sein:
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
Der Schlüssel ist, dass Sie, da Sie Windows verwenden,mussFühren Sie die OpenVPN-Anwendung als Administrator aus. Andernfalls werden im Protokoll Einträge wie die folgenden angezeigt:
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
Antwort4
Ich verwende hier FreshTomato. Mir ist es gelungen, nur 3 Ziel-IPs zum VPN umzuleiten.
Unten sehen Sie die benutzerdefinierte OpenVPN-Konfiguration:
allow-pull-fqdn
route-nopull
script-security 2
up /opt/openvpn-routes.sh
Dann das oben erwähnte Skript:
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
Der Einhängepunkt /opt wurde gemäß den Anweisungen vonhttps://github.com/Entware/Entware/wiki/Install-on-TomatoUSB-and-FreshTomato