staging.inyokaproject.org

VPN Gateway einrichten

Status: Gelöst | Ubuntu-Version: Server 18.04 (Bionic Beaver)
Antworten |

thor17

Avatar von 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)
Avatar von thor17

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: 14402

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)
Avatar von thor17

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: 14402

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)
Avatar von thor17

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: 14402

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)
Avatar von thor17

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: 14402

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)
Avatar von thor17

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

1
2
3
4
5
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

1
2
3
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: 14402

thor17 schrieb:

route -n

1
2
3
4
5
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)
Avatar von thor17

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: 14402

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).

Antworten |