thor17
Anmeldungsdatum: 18. Dezember 2011
Beiträge: 222
|
Hallo! Ich möchte gern meinen Ubuntu Server als VPN(Client) Gateway nutzen. Bisher reichte mein Route dafür, aber für die schnellere Leitung ist der Router zu langsam.
Alle Geräte befinden sich im selben Netzwerk. Ich habe OpenVPN als Client auf dem Server eingerichtet, das funktioniert soweit, der Server nutzt die VPN Verbindung.
Das einzige was ich jetzt noch umsetzen muss ist, dass der gesamte Traffic meiner PCs/Laptops über den Server an den VPN Tunnel weitergerreicht wird,zumindest das, was ins Internet soll bzw. von da kommt.
Ich hatte vor etlichen Jahren so eine Konfiguration auf einem anderen Server laufen, aber ich kann mich nicht mehr daran erinnern, wie genau ich das damals umgesetzt habe. Ich kann mich noch daran erinnern, das mit iptables gemacht zu haben. Kann mir da vielleicht jemand weiterhelfen? Danke!
|
thor17
(Themenstarter)
Anmeldungsdatum: 18. Dezember 2011
Beiträge: 222
|
Ich hab mal die Regeln wie auf dieser Seite probiert, leider kein Erfolg, ich bekomme einfach keine Verbindung. Mein PC kann keine Adresse auflösen wenn ich den Server als Gateway einstelle. https://arashmilani.com/post?id=53
|
lubux
Anmeldungsdatum: 21. November 2012
Beiträge: 13931
|
thor17 schrieb: Ich habe OpenVPN als Client auf dem Server eingerichtet, das funktioniert soweit, der Server nutzt die VPN Verbindung.
Wie nutzt der Server (als VPN-Client) die VPN-Verbindung? Geht der komplette Internettraffic des Servers, über diese VPN-Verbindung? Wer betreibt den VPN-Server bzw. wo befindet sich der VPN-Server?
|
thor17
(Themenstarter)
Anmeldungsdatum: 18. Dezember 2011
Beiträge: 222
|
lubux schrieb: thor17 schrieb: Ich habe OpenVPN als Client auf dem Server eingerichtet, das funktioniert soweit, der Server nutzt die VPN Verbindung.
Wie nutzt der Server (als VPN-Client) die VPN-Verbindung? Geht der komplette Internettraffic des Servers, über diese VPN-Verbindung? Wer betreibt den VPN-Server bzw. wo befindet sich der VPN-Server?
Der lokale Server nutzt openvpn um zu einem der NordVPN Server eine Verbindung aufzubauen. Soweit funktioniert das auch, der Server ist verbunden und der Traffic vom Server läuft über den VPN Anbieter. Ich habe gerade diese Regeln getestet, leider auch kein Erfolg
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27 | # Allow traffic initiated from VPN to access LAN
iptables -I FORWARD -i tun0 -o enp2s0 \
-s 10.8.0.0/24 -d 192.168.1.0/24 \
-m conntrack --ctstate NEW -j ACCEPT
# Allow traffic initiated from VPN to access "the world"
iptables -I FORWARD -i tun0 -o enp2s0 \
-s 10.8.0.0/24 -m conntrack --ctstate NEW -j ACCEPT
# Allow traffic initiated from LAN to access "the world"
iptables -I FORWARD -i enp2s0 -o tun0 \
-s 192.168.1.0/24 -m conntrack --ctstate NEW -j ACCEPT
# Allow established traffic to pass back and forth
iptables -I FORWARD -m conntrack --ctstate RELATED,ESTABLISHED \
-j ACCEPT
# Notice that -I is used, so when listing it (iptables -vxnL) it
# will be reversed. This is intentional in this demonstration.
# Masquerade traffic from VPN to "the world" -- done in the nat table
iptables -t nat -I POSTROUTING -o enp2s0 \
-s 10.8.0.0/24 -j MASQUERADE
# Masquerade traffic from LAN to "the world"
iptables -t nat -I POSTROUTING -o enp2s0 \
-s 192.168.1.0/24 -j MASQUERADE
|
|
lubux
Anmeldungsdatum: 21. November 2012
Beiträge: 13931
|
thor17 schrieb: Der lokale Server nutzt openvpn um zu einem der NordVPN Server eine Verbindung aufzubauen. Soweit funktioniert das auch, der Server ist verbunden und der Traffic vom Server läuft über den VPN Anbieter.
Hast Du auf deinem Server:
sudo sysctl -w net.ipv4.ip_forward=1
konfiguriert (das ist noch nicht persistent)? Die default policy der FORWARD chain sollte auf ACCEPT sein und es sollten wenn möglich keine Regeln für die FORWARD chain konfiguriert sein. Für alle Interfaces sollte eine source-NAT (MASQUERADE)-Regel gesetzt sein. Wenn Du ufw (oder gleichwertig) auf dem Server aktiviert hast, kann ich dir nicht helfen. Wie ist jetzt auf dem Server die Ausgabe von:
sudo iptables -nvx -L
?
|
thor17
(Themenstarter)
Anmeldungsdatum: 18. Dezember 2011
Beiträge: 222
|
lubux schrieb: thor17 schrieb: Der lokale Server nutzt openvpn um zu einem der NordVPN Server eine Verbindung aufzubauen. Soweit funktioniert das auch, der Server ist verbunden und der Traffic vom Server läuft über den VPN Anbieter.
Hast Du auf deinem Server:
sudo sysctl -w net.ipv4.ip_forward=1
konfiguriert (das ist noch nicht persistent)? Die default policy der FORWARD chain sollte auf ACCEPT sein und es sollten wenn möglich keine Regeln für die FORWARD chain konfiguriert sein. Für alle Interfaces sollte eine source-NAT (MASQUERADE)-Regel gesetzt sein. Wenn Du ufw (oder gleichwertig) auf dem Server aktiviert hast, kann ich dir nicht helfen. Wie ist jetzt auf dem Server die Ausgabe von:
sudo iptables -nvx -L
?
ipv4 forward ist bereits persisten in /etc/systctl konfiguriert. 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32 | Chain INPUT (policy ACCEPT 560713 packets, 1062083884 bytes)
pkts bytes target prot opt in out source destination
0 0 ACCEPT udp -- virbr0 * 0.0.0.0/0 0.0.0.0/0 udp dpt:53
0 0 ACCEPT tcp -- virbr0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:53
0 0 ACCEPT udp -- virbr0 * 0.0.0.0/0 0.0.0.0/0 udp dpt:67
0 0 ACCEPT tcp -- virbr0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:67
0 0 ACCEPT udp -- virbr0 * 0.0.0.0/0 0.0.0.0/0 udp dpt:53
0 0 ACCEPT tcp -- virbr0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:53
0 0 ACCEPT udp -- virbr0 * 0.0.0.0/0 0.0.0.0/0 udp dpt:67
0 0 ACCEPT tcp -- virbr0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:67
Chain FORWARD (policy ACCEPT 5 packets, 212 bytes)
pkts bytes target prot opt in out source destination
0 0 ACCEPT all -- * virbr0 0.0.0.0/0 192.168.122.0/24 ctstate RELATED,ESTABLISHED
0 0 ACCEPT all -- virbr0 * 192.168.122.0/24 0.0.0.0/0
0 0 ACCEPT all -- virbr0 virbr0 0.0.0.0/0 0.0.0.0/0
0 0 REJECT all -- * virbr0 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable
0 0 REJECT all -- virbr0 * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable
0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 ctstate RELATED,ESTABLISHED
85 5889 ACCEPT all -- enp2s0 tun0 192.168.1.0/24 0.0.0.0/0 ctstate NEW
0 0 ACCEPT all -- tun0 enp2s0 10.8.0.0/24 0.0.0.0/0 ctstate NEW
0 0 ACCEPT all -- tun0 enp2s0 10.8.0.0/24 192.168.1.0/24 ctstate NEW
0 0 ACCEPT all -- * virbr0 0.0.0.0/0 192.168.122.0/24 ctstate RELATED,ESTABLISHED
0 0 ACCEPT all -- virbr0 * 192.168.122.0/24 0.0.0.0/0
0 0 ACCEPT all -- virbr0 virbr0 0.0.0.0/0 0.0.0.0/0
0 0 REJECT all -- * virbr0 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable
0 0 REJECT all -- virbr0 * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable
Chain OUTPUT (policy ACCEPT 115545 packets, 9213841 bytes)
pkts bytes target prot opt in out source destination
0 0 ACCEPT udp -- * virbr0 0.0.0.0/0 0.0.0.0/0 udp dpt:68
0 0 ACCEPT udp -- * virbr0 0.0.0.0/0 0.0.0.0/0 udp dpt:68
|
|
lubux
Anmeldungsdatum: 21. November 2012
Beiträge: 13931
|
thor17 schrieb: ipv4 forward ist bereits persisten in /etc/systctl konfiguriert.
OK. Jetzt sollte man testen, ob die Konfiguration des VPN-Clienten (für NordVPN) den Server als VPN-gateway zulässt. Was für ein Gerät (PC/Laptop mit welchem Betriebssystem?) ist das, das via Server/VPN ins Internet soll?
|
thor17
(Themenstarter)
Anmeldungsdatum: 18. Dezember 2011
Beiträge: 222
|
Auf PC und Laptop läuft jeweils Ubuntu 18.04 Desktop.
|
lubux
Anmeldungsdatum: 21. November 2012
Beiträge: 13931
|
thor17 schrieb: Auf PC und Laptop läuft jeweils Ubuntu 18.04 Desktop.
Wie sind auf dem Laptop die Ausgaben von:
ip a
route -n
ip n s
?
|
thor17
(Themenstarter)
Anmeldungsdatum: 18. Dezember 2011
Beiträge: 222
|
ip a
1
2
3
4
5
6
7
8
9
10
11
12
13
14 | 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
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: enp0s25: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether 68:f7:28:35:dd:5f brd ff:ff:ff:ff:ff:ff
inet 192.168.1.130/24 brd 192.168.1.255 scope global noprefixroute enp0s25
valid_lft forever preferred_lft forever
inet6 fe80::dfb1:b8c9:9d85:1673/64 scope link noprefixroute
valid_lft forever preferred_lft forever
3: wlp3s0: <BROADCAST,MULTICAST> mtu 1500 qdisc mq state DOWN group default qlen 1000
link/ether e8:b1:fc:d0:d8:10 brd ff:ff:ff:ff:ff:ff
|
route -n
| Kernel-IP-Routentabelle
Ziel Router Genmask Flags Metric Ref Use Iface
0.0.0.0 192.168.1.1 0.0.0.0 UG 100 0 0 enp0s25
169.254.0.0 0.0.0.0 255.255.0.0 U 1000 0 0 enp0s25
192.168.1.0 0.0.0.0 255.255.255.0 U 100 0 0 enp0s25
|
ip n s
| 192.168.1.1 dev enp0s25 lladdr 14:cc:20:e5:8e:83 REACHABLE
192.168.1.6 dev enp0s25 lladdr 70:85:c2:04:0e:57 STALE
192.168.1.14 dev enp0s25 lladdr c0:41:f6:6f:3d:ee STALE
|
Das einzige was ich an dieser Konfig ändern muss ist das Gateway und den DNS auf 192.168.1.6 einzusztellen. Das hat früher prima funktioniert, der Fehler liegt bei der Serverkonfig. Vielleich hats was mit ufw zutun?
|
lubux
Anmeldungsdatum: 21. November 2012
Beiträge: 13931
|
thor17 schrieb: route -n
| Kernel-IP-Routentabelle
Ziel Router Genmask Flags Metric Ref Use Iface
0.0.0.0 192.168.1.1 0.0.0.0 UG 100 0 0 enp0s25
169.254.0.0 0.0.0.0 255.255.0.0 U 1000 0 0 enp0s25
192.168.1.0 0.0.0.0 255.255.255.0 U 100 0 0 enp0s25
|
Das einzige was ich an dieser Konfig ändern muss ist das Gateway und den DNS auf 192.168.1.6 einzusztellen. Das hat früher prima funktioniert, der Fehler liegt bei der Serverkonfig. Vielleich hats was mit ufw zutun?
Versuch mal mit_
sudo route add default gw 192.168.1.6 metric 0 dev enp0s25
mtr -4nr -c 1 1.1.1.1
Ich denke ufw ist bei dir nicht aktiv.
|
thor17
(Themenstarter)
Anmeldungsdatum: 18. Dezember 2011
Beiträge: 222
|
Hab ich schon, funktioniert wie gesagt nicht.
Die meisten Tutorials mit diesem Thema nutzen ein zweites Interface. Also ein Interface das mit dem Internet verbunden ist und eins das für lokale Verbindungen da ist. So hab ich das damals auch gemacht, aber leider kann ich mich nicht mehr an die Details der Konfig erinnern.
|
lubux
Anmeldungsdatum: 21. November 2012
Beiträge: 13931
|
thor17 schrieb: Die meisten Tutorials mit diesem Thema nutzen ein zweites Interface. Also ein Interface das mit dem Internet verbunden ist und eins das für lokale Verbindungen da ist.
Das ist aber nicht erforderlich. Entscheidend ist das Routing. Die default route ist für das Internet und die definierte Route für localnet, ist für die lokalen Verbindungen zuständig. Bei (noch) 2 default Routen, ist die metric wichtig. Wie ist die Ausgabe von:
route -n
mit der 2. default route? Teste auf dem Server mit tcpdump (oder gleichwertig) ob am Traffic/Datenverkehr vom Client, dort ankommt (wenn der Client diese 2. default route hat).
|