Übrige Public IP via VPN daheim nutzen: Konzept?

[alex0801]

Hey,

folgendes Szenario:

Ich hab einen Root-Server mit zwei public IPv4 Adressen (leider beide aus unterschiedlichen Netzen/Subnetzen). Eine davon würde ich gerne irgendwie per VPN meinem Server daheim an der DSL-Leitung zur Verfügung stellen. Sprich: Mein kleiner Debian-Server daheim am DSL Anschluss soll mit der zweiten Public-IP des Root-Servers über's Internet erreichbar sein. Eben so, als stünde er in einem Rechenzentrum und hätte eine Public-IP. Nur eben mit weniger Bandbreite (das ist aber okay für mich, bald kommt ein FTTH mit synchronem 100mbit Anschluss).

Mein erster Ansatz war jetzt:

* OpenVPN auf den Root-Server installieren
* Homeserver mit OpenVPN Server verbinden lassen
* Netzwerkschnittstelle des root-servers mit der zweiten IP mit dem OpenVPN Device brücken...

Wie ich jetzt weiß geht das nicht. Meine beiden Public-IPs des Root-Servers sind aus unterschiedlichen Netzen. Ich kann also nicht einfach die zweite IP per OpenVPN "weitergeben". Das würde wohl gehen, wenn ich beide Public IPs im selben Subnetz hätte.

Aktuell würde ich zu "Masquerading" über IP Tables tendieren. Aber damit würde ich die IP ja auch nicht weitergeben an meinen Homeserver, sondern nur meine private IP des Homeservers hinter der zweiten Public-IP des Root-Servers "verstecken".

Hat noch jemand ne Idee wie ich die zweite Public-IP am Homeserver nutzen könnte?

Gegebenheiten am Root-Server:

Die beiden Public-IPs mit ihren Interfaces:
eth0: 80.xxx.xxx.xxx netmask 255.255.255.192
eth1: 212.xxx.xxx.xxx netmask 255.255.255.0

Gruß
Alex

[bluestar]

Hat noch jemand ne Idee wie ich die zweite Public-IP am Homeserver nutzen könnte?

Du richtest einfach einen OpenVPN Tun-Tunnel /30 Netz mit privaten IPs und routest deine zweite öffentliche IP einfach an den OpenVPN Endpunkt deines Home-Servers.

Dazu brauchst du noch auf deinem Home-Server source based routing, d.h. alles was von der Public IP geht muss über den OpenVPN Tunnel zurück.

[alex0801]

Du richtest einfach einen OpenVPN Tun-Tunnel /30 Netz mit privaten IPs

Das ist ja das was OpenVPN per Default tut: Ein 10.8.x.x Netz aufmachen und den Clients eine IP daraus zuweisen. Oder bin ich da jetzt falsch?

Und mein Homeserver hätte dann ja doch wieder eine "private IP". Wenn ich da nun einen z.B. Mailserver aufsetzen will, dann hat der ja überall die private IP drin stehen und nicht die öffentliche?

und routest deine zweite öffentliche IP einfach an den OpenVPN Endpunkt deines Home-Servers.

wie würde dieses "routing" denn aussehen? Hast du da noch ein paar Stichwörter die mir bei der Suche weiter helfen?

[bluestar]

wie würde dieses "routing" denn aussehen? Hast du da noch ein paar Stichwörter die mir bei der Suche weiter helfen?

Auf dem Server im Netz:

Code: Alles auswählen

ip route add a.b.c.d/32 via 10.x,y.z

a.b.c.d => öffentliche IP
10.x.y.z => IP des Tun-Devices auf deinem Home-Server.

Auf deinem Home-Server richtest du die IP auf irgendeinem Device ein:

Code: Alles auswählen

ip addr add a.b.c.d/32 dev eth0

Jetzt musst du noch das Source-Based Routing einrichten:

Code: Alles auswählen

ip route add default via 10.x,y.b table 2
ip rule add from a.b.c.d/32 lookup 2

Dazu legst du eine zweite Routingtabelle (1. Befehl) an und sagst, dass alles was von der öffentlichen IP a.b.c.d über die 10.x,y.b (Tun Devices deines Servers im Netz) ein.

[alex0801]

Vielen lieben Dank, das ist mehr Info als ich mir erhofft hatte. Ich werde das dann gleich probieren.

Gruß
Alex

[alex0801]

Hmm, klappt noch nicht so ganz.

Aktueller Stand:

Root:

Code: Alles auswählen

eth0: 80.___.___.223/26
eth1: 212.___.___.46/24
tun0: 10.8.1.1 peer 10.8.1.2/32 (10.8.1.2 ist also der GW ins VPN Netzwerk)

Homeserver:

Code: Alles auswählen

eth0: 192.168.200.3/24
tun1: 10.8.1.6 peer 10.8.1.5/32 (10.8.1.5 ist also für den homeserver der GW ins VPN Netz)

Auf dem Root habe ich, nach herstellen den VPN Verbindung ausgeführt:

Code: Alles auswählen

ip route add 212.___.___.46 via 10.8.1.2 dev tun0

In deinem beispiel stand hier noch die Netzmaske /32 drin. Kommt so aufs selbe raus. Das klappt aber denoch nicht mit der IP des Tun devices vom Homeserver. Hab gegoogelt und das hier gefunden: https://access.redhat.com/documentation ... tic-routes
Dort steht, dass ich mit obigem Befehl eine einzelne IP Adresse mit einer statischen Route versehe. Von meinem Verständnis her sollte das passen. Korrigiert mich wenn ich falsch liege. Und ich brauche hier die IP des VPN Peers, also den "Gateway" ins VPN Netz. Gebe ich hier die 10.8.1.6 IP vom Homeserver ein, kommt die Meldung dass die Adresse nicht erreicht werden kann. Pingen und SSH Verbindung vom Root auf 10.8.1.6 geht aber. Ich gehe davon aus, dass ich hier also tatsächlich die Peer IP nutzen muss?!

Die Routing-Tabelle (ip route) auf dem Root-Server sieht dann wie folgt aus:

Code: Alles auswählen

default via 80.___.___.129 dev eth0 
10.8.1.0/24 via 10.8.1.2 dev tun0 
10.8.1.2 dev tun0 proto kernel scope link src 10.8.1.1 
80.___.___.129 dev eth0 scope link 
80.___.___.192/26 dev eth0 proto kernel scope link src 80.___.___.223 
212.___.___.0/24 dev eth1 proto kernel scope link src 212.___.___.46 
212.___.___.46 via 10.8.1.2 dev tun0 

Sieht für mich nicht so verkehrt aus...

Soweit mal okay.

Auf dem Homeserver hab ich ausgeführt:

Code: Alles auswählen

ip addr add 212.___.___.46/24 dev eth0
ip route add default via 10.8.1.5 table 2
ip rule add from 212.___.___.46/24 lookup 2

Hier hab ich also für die 2.te Routing-tabelle den VPN Peer ins VPN Netz angegeben. Hier hattest du /32 angegeben, die IP ist aber in einem /24er Netz. Mir scheint es unlogisch zu sein hier eine tatsächliche IP *UND* eine Netzmaske anzugeben. Aber auch mit "212.___.___.0/24" ändert das die Sache erstmal nicht (siehe unten)

Die Routing-Tabelle (ip route) des Homeservers:

Code: Alles auswählen

default via 192.168.200.1 dev eth0 onlink 
10.8.1.1 via 10.8.1.5 dev tun1 
10.8.1.5 dev tun1 proto kernel scope link src 10.8.1.6 
192.168.200.0/24 dev eth0 proto kernel scope link src 192.168.200.3 
212.___.___.0/24 dev eth0 proto kernel scope link src 212.___.___.46 

Ich hab dann versucht von einem beliebigen Rechner im Internet aus eine SSH Verbindung zur 2ten Public-IP 212.___.___.46 aufzubauen. Aber ich lande damit nicht am Homeserver, sondern am Root-Server.
Ich hab das Gefühl ich muss dem Root-Server noch anders beibringen dass wirklich alles, was an 212.___.___.46 kommuniziert wird, ins VPN geschickt wird.

Ich steh nur noch etwas (schon wieder ...) auf dem Schlauch.

[update]

Hmm, die Reihenfolge scheinti nd er Routing-tabelle nicht zu passen:

root@rootserver:~# route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
default 80.___.___.129 0.0.0.0 UG 0 0 0 eth0
10.8.1.0 10.8.1.2 255.255.255.0 UG 0 0 0 tun0
10.8.1.2 0.0.0.0 255.255.255.255 UH 0 0 0 tun0
80.___.___.129 0.0.0.0 255.255.255.255 UH 0 0 0 eth0
80.___.___.192 0.0.0.0 255.255.255.192 U 0 0 0 eth0
212.___.__.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
212.___.___.46 10.8.1.2 255.255.255.255 UGH 0 0 0 tun0

Wenn die suche nach der richtigen Rute von oben nach unten in dieser Reihenflge durch geht, findet er zuerst die route über eth1 statt die route über tun0 wenn man zu 212.___.___.46 senden will ... Ich probier mal die metriken anzupassen. ich meine damit beeinfluss man die reihenfolge.

[update2]
hat nix geholfen:

root@rootserver:~# route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
default 80.___.___.129 0.0.0.0 UG 0 0 0 eth0
10.8.1.0 10.8.1.2 255.255.255.0 UG 0 0 0 tun0
10.8.1.2 0.0.0.0 255.255.255.255 UH 0 0 0 tun0
80.___.___.129 0.0.0.0 255.255.255.255 UH 0 0 0 eth0
80.___.___.192 0.0.0.0 255.255.255.192 U 0 0 0 eth0
212.___.__.0 0.0.0.0 255.255.255.0 U 1 0 0 eth1
212.___.___.46 10.8.1.2 255.255.255.255 UGH 0 0 0 tun0

Problem ist noch das selbe. Müsste ich nicht im erfolgsfall auf dem Rootserver mit "traceroute" sehen dass er über die VPN Verbindung routet? Das geht immer noch direkt, ein einziger hop

[bluestar]

Ah, deine zweite IP kommt über ein Ethernet-Interface, dann musst du Proxy_arp auf dem entsprechenden Interface einschalten und die IP darf natürlich nicht auf eth1 konfiguriert sein.

[alex0801]

Jepp, hatte ich doch weiter oben schon geschrieben.

proxy_arp ... muss ich mal googeln. Danke für den Hinweis.

[update]
gefunden:

Code: Alles auswählen

echo 1 > /proc/sys/net/ipv4/conf/eth1/proxy_arp

sowie:

Code: Alles auswählen

ip addr del 212.___.___.46/24 dev eth1

Ein traceroute auf die Public IP vom Rootserver aus bringt jetzt gar keinen hop mehr
Vom einem beliebigen Rechnr aus ein traceroute auf die 2te Public IP enden die hops bei der 1sten IP des Rootservers.

D.h. die daten kommen wohl an, gehen aber nicht weiter.

[alex0801]

Hmm,
sieht eigentlich nun "richtiger" aus. Kein lokales Device hat mehr die IP, und alles was an die IP geht, geht an den Peer des VPN...

Code: Alles auswählen

root@rootserver:~# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         80.___.___.129  0.0.0.0         UG    0      0        0 eth0
10.8.1.0        10.8.1.2        255.255.255.0   UG    0      0        0 tun0
10.8.1.2        0.0.0.0         255.255.255.255 UH    0      0        0 tun0
80.___.___.129  0.0.0.0         255.255.255.255 UH    0      0        0 eth0
80.___.___.192  0.0.0.0         255.255.255.192 U     0      0        0 eth0
212.___.___.46   10.8.1.2        255.255.255.255 UGH   0      0        0 tun0

root@rootserver:~# traceroute 212.___.___.46
traceroute to 212.___.___.46 (212.___.___.46), 30 hops max, 60 byte packets
 1  * * *
 2  * * *
 3  * * *
 4  * * *
 5  * * *
 6  *^C

Aber kein einziger hop

[alex0801]

Wenn ich von irgendwoher einen ping auf die 2te public IP mache, und auf dem Rootserver ein tcpdump -i tun0 mache, sehe ich dass hier ICMP echo requests am tun0 interface ankommen:

Code: Alles auswählen

root@rootserver:~# tcpdump -i tun0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun0, link-type RAW (Raw IP), capture size 262144 bytes
21:18:27.654632 IP p54911xxx.dip0.t-ipconnect.de > 212.___.___.46: ICMP echo request, id 808, seq 5, length 64
21:18:28.678640 IP p54911xxx.dip0.t-ipconnect.de > 212.___.___.46: ICMP echo request, id 808, seq 6, length 64
^C

Mache ich ein tcpdump -i eth1 auf dem Homeserver, sehe ich überhaupt nix. Absolut null traffic.

heißt: Es kommt am Root-Server an, und geht auf tun0, aber geht nicht durch den VPN tatsächlich hindurch. Fast so, als würde das nichts weitergeleitet werden

[bluestar]

Kannst du die IPs von tun0 gegenseitig pingen??

[alex0801]

Rootserver: ping 10.8.1.6 -> geht
Homeserver: ping 10.8.1.1 -> geht
Vom rootserver auf die 212.___.___.46 -> geht nicht
Von irgendwo im Interner auf die 212.___.___.46 -> geht nicht

d.h. der Tunnel steht und funktioniert. Aber die public-ip will da nicht durch. Wie gesagt: Wenn ich von irgendwo die public IP pinge, sehe ich den Traffic wenn ich "tcpdump -i tun0" auf dem root-server laufen lasse.
D.h. ich komme bis zum tunnel, aber entweder mit dieser IP nicht durch, oder nicht zurück.

[bluestar]

Rootserver: ping 10.8.1.6 -> geht

Kannst du die 10.8.1.2 pingen?

[alex0801]

Code: Alles auswählen

root@rootserver:~# ip route add 212.___.___.46 via 10.8.1.6 dev tun0 
RTNETLINK answers: Network is unreachable

aber:

Code: Alles auswählen

root@rootserver:~# ping 10.8.1.6
PING 10.8.1.6 (10.8.1.6) 56(84) bytes of data.
64 bytes from 10.8.1.6: icmp_seq=1 ttl=64 time=17.1 ms
64 bytes from 10.8.1.6: icmp_seq=2 ttl=64 time=15.1 ms
^C

und

Code: Alles auswählen

root@rootserver:~# ping 10.8.1.2
PING 10.8.1.2 (10.8.1.2) 56(84) bytes of data.

Und jetzt? Ich verstehe das "via" als "gateway-adresse". Und der "gateway", also die "peer"-IP ist 10.8.1.2 und die kann ich auch als "via" angeben.


[update]

"ip addr" ergibt für tun0

Code: Alles auswählen

17: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 100
    link/none 
    inet 10.8.1.1 peer 10.8.1.2/32 scope global tun0
       valid_lft forever preferred_lft forever
    inet6 fe80::395a:cf8f:d050:f431/64 scope link flags 800 
       valid_lft forever preferred_lft forever

ich verstehe die "peers" als "gateway/router" ins vpn netz:

rootserver vpn ip 10.8.1.1 --> [rootserver peer: 10.8.1.2] <<<<>>>>> [homeserver peer: 10.8.1.5] <-- 10.8.1.6 homeserver vpn ip

von daher würde das passen dass ich den peer angeben muss.

Ich schätze viel eher, dass der homeserver nicht auf den ping zurückantworten kann. Ist nur die frage warum ...

[bluestar]

Kannst du deine OpenVPN Configs mal posten

[alex0801]

server auf rootserver:

Code: Alles auswählen

root@rootserver:~# cat /etc/openvpn/server/server.conf | grep -v "#" | grep -v ";"

local 80.___.___.223
port 1194
proto udp
dev tun
ca /etc/openvpn/server/ca.crt
cert /etc/openvpn/server/server.crt
dh /etc/openvpn/server/dh4096.pem
server 10.8.1.0 255.255.255.0
ifconfig-pool-persist ipp.txt
keepalive 10 120
tls-auth /etc/openvpn/server/ta.key 0 
cipher AES-256-CBC
max-clients 1
persist-key
persist-tun
status openvpn-status.log
verb 3
explicit-exit-notify 1
mode server
tls-server
auth sha512

client auf homeserver:

Code: Alles auswählen

root@homeserver:/etc/openvpn/client# cat client.conf | grep -v "#" | grep -v ";"

client
dev tun
proto udp
remote 80.___.___.223 1194
resolv-retry infinite
nobind
persist-key
persist-tun
ca /etc/openvpn/client/ca.crt
cert /etc/openvpn/client/client.crt
key /etc/openvpn/client/client.key
remote-cert-tls server
tls-auth /etc/openvpn/client/ta.key 1
cipher AES-256-CBC
verb 3
auth SHA512
tls-client

[alex0801]

Muss denn am Homeserver in der routing-tabelle nicht auch die public-ip irgendwie bekannt sein?

Code: Alles auswählen

root@homeserver:/etc/openvpn/client# route -n
Kernel-IP-Routentabelle
Ziel            Router          Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.200.1   0.0.0.0         UG    0      0        0 eth0
10.8.0.0        10.8.0.2        255.255.255.0   UG    0      0        0 tun0
10.8.0.2        0.0.0.0         255.255.255.255 UH    0      0        0 tun0
10.8.1.1        10.8.1.5        255.255.255.255 UGH   0      0        0 tun1
10.8.1.5        0.0.0.0         255.255.255.255 UH    0      0        0 tun1
192.168.200.0   0.0.0.0         255.255.255.0   U     0      0        0 eth0

Weil, wenn Pakete an die IP 212.__.___.46 durch den OpenVPN Tunnel am Homeserver ankämen, weiß man anhand der Routing-tabelle ja gar nicht was damit zu tun ist... Oder reicht es tatsächlich dass eth0 am Homeserver einfach eine zweite IP hat:

Code: Alles auswählen

2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether dc:9c:52:07:xx:xx brd ff:ff:ff:ff:ff:ff
    inet 192.168.200.3/24 brd 192.168.200.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet 212.___.___.46/32 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::de9c:52ff:fe07:bba6/64 scope link 
       valid_lft forever preferred_lft forever

[bluestar]

Hat das einen Grund, dass du OpenVPN mit TLS für so eine Verbindung nutzt?

Ich würde dir zu einem statischen Punkt-zu-Punkt-Tunnel für das Routing raten, Beispielconfigs:
Code für deinen Root-Server (a.b.c.d = die öffentliche IP, die du darüber routen willst)

Code: Alles auswählen

dev		tun0
proto		udp
lport		1194
secret		/etc/openvpn/server/tun0.key
cipher		CAMELLIA-256-CBC
auth		SHA1
keepalive	10 60
engine		rdrand
ifconfig	10.8.1.1 10.8.1.2
route		a.b.c.d 255.255.255.255
max-clients	1

Code für deinen Home-Server(a.b.c.d = OpenVPN Endpunkt)

Code: Alles auswählen

remote		a.b.c.d
proto		udp
dev		tun0
lport		1195
secret		/etc/openvpn/server/tun0.key
cipher		CAMELLIA-256-CBC
auth		SHA1
keepalive	10 60
engine		rdrand
ifconfig	10.8.1.2 10.8.1.1

[alex0801]

Nein, hat keinen speziellen Grund. Meinst du das Änderung auf p2p löst das ganze?

[alex0801]

tatsächlich, das löst das ganze ... Super. Vielen dank, oh mein Routing-Gott

Für die Nachwelt werde ich das gleich mal noch dokumentieren... [stay tuned]

[alex0801]

So, abschließen nochmal die Zusammenfassung der funktionierenden Konfiguration:

Rootserver:

Code: Alles auswählen

eth0: ip 80.___.___.223  netmask 255.255.255.192 <--------- Hierhin baut der Homeserver seine VPN Verbindung auf:
eth1: ip 212.___.___.46 netmask 255.255.255.0 <------- das ist die zweite public IP die über VPN dem Homeserver gehören soll

Homeserver:

Code: Alles auswählen

eth0: 192.168.200.3 netmask 255.255.255.0 <------- Netzwerkinterface für das Netzwerk "zuhause"

OpenVPN server.conf:

Code: Alles auswählen

local           80.___.___.223
dev             tun0
proto           udp
lport           1194
secret          /etc/openvpn/server/static.key
cipher          AES-256-CBC
auth            SHA256
keepalive       10 60
#engine         rdrand
engine          dynamic
ifconfig        10.8.1.1 10.8.1.2
route           212.___.___.46 255.255.255.255
max-clients     1
script-security 2
route-up "/etc/openvpn/server/up.sh"
route-pre-down "/etc/openvpn/server/down.sh"

up.sh

Code: Alles auswählen

#!/bin/sh
echo 1 > /proc/sys/net/ipv4/conf/eth1/proxy_arp
/sbin/ip addr del 212.___.___.46/24 dev eth1
/sbin/ip route add 212.___.___.46 via 10.8.1.2 dev tun0

down.sh

Code: Alles auswählen

#!/bin/sh
/sbin/ip route del 212.___.___.46 via 10.8.1.2 dev tun0
/sbin/ip addr add 212.___.___.46/24 dev eth1
echo 0 > /proc/sys/net/ipv4/conf/eth1/proxy_arp

OpenVPN client.conf

Code: Alles auswählen

remote          80.___.___.223
proto           udp
dev             tun1 # hab auf dem client noch eine andere OpenVPN config die tun0 benutzt, deshalb her tun1, sonst wäre es auch tun0
lport           1195
secret          /etc/openvpn/client/static.key
cipher          AES-256-CBC
auth            SHA256
keepalive       10 60
#engine         rdrand
engine          dynamic
ifconfig        10.8.1.2 10.8.1.1
script-security 2
route-up "/etc/openvpn/client/up.sh"
route-pre-down "/etc/openvpn/client/down.sh"

up.sh

Code: Alles auswählen

#!/bin/sh
ip addr add 212.___.___.46/32 dev eth0
ip route add default via 10.8.1.2 table 2
ip rule add from 212.___.___.46/32 lookup 2

down.sh

Code: Alles auswählen

!/bin/sh
ip rule del from 212.___.___.46/32 lookup 2
ip route del default via 10.8.1.2 table 2
ip addr del 212.___.___.46/32 dev eth0

Auf dem Homeserver kann man dann basierend auf "tun0" und der IP "212.___.___.46" mit iptables prima Firewallregeln anlegen.