OpenVPN tunnel Mit Internetzugang

[spoi]

Hallo,

ich möchte eine IP, die auf Server A Connectiert ist auf Server B via OpenVPN verfügbar machen.
Konkret soll also Server B sich mittels OpenVPN Client an Server A Anmelden und dann soll der gesamte netzwerk traffic, der bei Server A auf einer bestimmten IP ankommt nach Server B über den VPN tunnel geleitet werden, genauso sollen natürlich auch die Antworten über den Tunnel zurück. Was nicht passieren soll ist, dass Server B nurnoch über den VPN Tunnel online gehen kann.

Hat das hier schon einmal jemand gebaut bzw. kennt jemand ein entsprechendes tutorial. Ich habe hier schon einige Konfigurationsversuche gestartet, aber bis das ich die Netzwerkverbindung von Server A geschrottet habe, hat sich noch kein Erfolg eingestellt.

Gruß,
spoi

[lordy]

Ich geb dir mal ein paar Stichpunkte, vielleicht hilft das schon:

- Tunnel aufbauen
- Tunnelenden von beiden enden pingen
- Auf Server-A SNAT via IPtables einrichten
- Auf Server-B die entsprechende(n) Route(n) auf den Tunnel umbiegen

Wenn du mehr Details brauchst poste mal deine echte Config, dann
kann man dir konkrete Hilfestellung geben.

[spoi]

Meine OpenVPN Server config sieht zur Zeit so aus:

port 1194
proto udp
dev tap

# Server-Einstellungen
mode server
tls-server
server 10.0.0.0 255.255.255.0
client-to-client

# Authentifizierung und Verschluesselung
ca ca.crt
cert server.crt
key server.key
dh dh1024.pem
auth SHA1
cipher AES-256-CBC
# Sonstiges
ping 10
push "ping 10"
ping-restart 60
push "ping-restart 60"

dann bekomme ich auch eine Verbindung von openVPN Server zu client (über die ip 10.0.0.1 und 10.0.0.2 halt)

Wo es bei mir momentan noch hackt ist bei SNAT und IPTables bzw. bei den routen auf Server B

[lordy]

Auf Server-A:

iptables -t nat -A POSTROUTING -s 10.0.0.2 -o <ausgehendes Interface> -j SNAT --to <offizielle IP>

Das sollte eigentlich schon reichen. Mehr Details findest du hier:
http://www.netfilter.org/documentation/ ... html#ss6.1

Auf Server-B kannst du dann eine Test-Route wie folgt setzen:

route add -net 192.0.2.0/24 gw 10.0.0.1

Wenn du dann ein "traceroute 192.0.2.1" machst sollte der erste Hop Server-A sein.

[spoi]

scheint nicht zu gehen, scheint aber auch nicht richtig in die IP Tables eingetragen zu werden siehe:

:~# iptables --list
Chain INPUT (policy ACCEPT)
target prot opt source destination

Chain FORWARD (policy ACCEPT)
target prot opt source destination

Chain OUTPUT (policy ACCEPT)
target prot opt source destination

[theomega]

Code: Select all

iptables -L -t nat

lies am besten mal die Doku zu IPtables durch, das hilft!

[spoi]

habe ich das:
iptables -t nat -A POSTROUTING -s 10.0.0.2 -o <ausgehendes Interface> -j SNAT --to <offizielle IP>
jetzt richtig verstanden?

das sorgt doch dafür, dass Pakete die von 10.0.0.2 kommen über das Interface und die offizielle IP des Servers A ins netz gelangen?

Viel wichtiger ist mir jedoch, dass Pakete, die an die offizielle Adresse gerichtet sind an die 10.0.0.2 weitergeleitet werden

[oxygen]

Ich kann mich täuschen, aber so wie ich das sehe ist eine Konstellation exakt wie er sich das vorstellt gar nicht möglich. Insbesondere nicht, dass die Antworten über den Tunnel zurück gehen sollen.

[spoi]

naja wegen mir müssen die Antworten nicht über den tunnel zurück

ich brauche nur auf dem zweiten Server diese IP. Sprich wenn jemand eine Anfrage an diese IP Stellt soll die eben nicht von Server A auf den die IP providerseitig connectiert ist beantwortet werden sondern von Server B.

Sowas muss aber gehen, denn ich weis, dass es Dienste gibt, die einem Rechner an einem DSL Anschluss über einen vpn tunnel eine Statische IP zur Verfügung stellen.

[spoi]

gerne dürfen die Pakete natürlich über das vpn zurück (ich dachte eigentlich auch das dies die einfachere Lösung ist).

Was ich bis dato nicht hin bekomme ist das "alles Standard konfigurieren".
Was muss ich auf Server A einstellen, dass das teil als Gateway arbeitet und die Sachen an Server B weitergibt?

[oxygen]

Er wollte ja, dass die normale Internet Verbindung nicht beeinträchtigt wird (was ja auch Sinn macht) und der Traffic der übers VPN reinkommt, auch übers VPN rausgeht. Der Server kann aber nur einen default Gateway haben. Eine Trennung nach der Quelle der eingehenden Verbindung ist meines Wissens nicht möglich.
Wenn man damit leben kann, dass die Antwortpakete einen andern Weg nehmen, sollte Der Rest eigentlich kein großes Problem darstellen, das ginge auch ohne VPN recht einfach.

[spoi]

ich kann mit beidem leben, traffic über vpn zurück oder nicht

Das Hauptproblem ist doch erstmal, wie bekomme ich den Traffic überhaupt HIN, sonst brauch ich mir über das zurück noch keine Gedanken zu machen.

Oxygen, wie kann ich das hin realisieren? mit oder ohne VPN ist mir egal?

[oxygen]

Das leitet Port 80 von ServerA nach ServerB:

Code: Select all

echo "1" > /proc/sys/net/ipv4/ip_forward
iptables -A FORWARD --dport 80 -j ACCEPT
iptables -t nat -A PREROUTING -p tcp -d IPSERVERA --dport 80 -j DNAT --to-destination SERVERB

Allerdings bin ich mir im moment doch nicht mehr so sicher ob das funktionieren würde. Ich weiß nicht was passiert, wenn die Pakete auf dem Rückweg eine andere Route nehmen. Wäre möglich dass der Zielhost die dann verwirft.

[oxygen]

Die Dienste, die es betrifft auf die VPN IP binden.
Dann kann man die Anfragen und die Kommunikation etwas steuern.

Wenn er es so haben will, wie er es gesagt hat, muss er ja nur das Routing aktivieren und den Rechner Server A als Gateway definieren.

Demnach ist das reht einfach. Server B muss als Gateway den Server A erhalten.
Server A wiederum leitet explizit die Ports / Dienste an den Server B.

Fertig

Dann geht aber der komplette Traiffc über Server A und das soll ja nicht passieren.

[Joe User]

Man möge mich gerne korrigieren, aber er kann doch mehrere Routen und somit auch Gateways definieren. Unter Gentoo beispielsweise per:

Code: Select all

# /etc/conf.d/net
config_eth0=( "x.x.x.x/32 brd x.x.x.255" )
routes_eth0=(
        "y.y.y.y via y.y.y.1"
        "default via x.x.x.1"
)

Oder habe ich die Problematik falsch verstanden?

[oxygen]

[quote="oxygen"}Dann geht aber der komplette Traiffc über Server A und das soll ja nicht passieren.

Hatte er oben geschrieben, dass es ok wäre.
Zudem würde eine antwort, die direkt an den Server gerichtet wird, auch direkt beantwortet.
Da aber innerhalb der Kommunikation nur der Router weiss, woher eine Anfrage kam, muss dieser diese auch wieder zurück leiten.[/quote]
Nein es ist nicht ok, so würde man eine SPOF produzieren. Der normale Default Gateway sollte bestehen bleiben und nur die Pakete die zu Verbindungen die getunnelt werden, gehören, sollten übers VPN gehen. Oder als Alternative, gar keine ausgehenden Pakete übers VPN.
Joe: Aber 2 default Gateways geht nicht.

[Joe User]

Joe: Aber 2 default Gateways geht nicht.

Es wäre ja nur ein Default-Gateway/Route (x.x.x.1) für die öffentliche IP (x.x.x.x) und ein "simples" Gateway/Route (y.y.y.1) für das VPN (y.y.y.y).

[oxygen]

Ansonsten ist es mir unschlüssig, warum es möglich ist, in einen Rechner 2 Netzwerkarten zu stecken, und die antworten auf der jeweiligen Karte / Netz heraus kommt, über welches Sie gestellt wurde.

Das ist auch nicht möglich. Wer denn Kernel ein Paket versendet, wird einfach die Routingtabelle von oben nach unten abgearbeitet und die erste Route, die das Ziel enthält wird benutzt, ganz unabhängig davon, über welches Interface das erreicht wird.
In so einem Fall würde man dann Bonding/Trunking oder EQL benutzten. Oder das Zielnetz auf 2 Routen aufteilen.

[spoi]

wie bekomme ich es aber nun realisiert, dass Server A Anfragen auf 123.123.123.2 nach 10.0.0.2 routet?

[oxygen]

Es ist also nicht Möglich über einen Rechner 2 Netze zu bedienen?

Sorry, aber es scheint mir so, als verstehst du das Problem nicht richtig. Natürlich kann ich 2 Netzwerkkarten (oder allgemeiner 2 Devices) in einem Rechner haben. Aber jedes Ziel kann wird immer nur über eine route erreicht werden. Nehmen wir mal an wir haben ein Netzwerk 192.168.1.0/16. In einem Rechner stecken 2 Netzwerkkarten mit den IPs 192.168.1.1 (eth0) und .2 (eth1). Die Routingtabelle sieht dann z.B. so aus:

Code: Select all

route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.1.0   0.0.0.0         255.255.255.0 U     0      0        0 eth0
192.168.1.0   0.0.0.0         255.255.255.0 U     0      0        0 eth1
127.0.0.0     0.0.0.0         255.0.0.0     U     0      0        0 lo

Der Rechner wird dann nie über eth1 Pakete versenden, auch wenn Verbindungen auf der IP 192.168.1.2 ankommen.

Das gleiche Problem gab es hier in größer. Das ist Destination halt default. z.B. so:

Code: Select all

route -n
Destination     Gateway     Genmask         Flags Metric Ref    Use Iface
81.1.1.1       0.0.0.0     255.255.255.255 UH    0      0        0 eth0
10.10.10.0   0.0.0.0     255.255.0.0       U     0      0        0 tap0
default         81.1.1.1    0.0.0.0         UG    0      0        0 eth0

Wenn eine Anfrage aus dem Internet über NAT an ServerA's IP 10.10.10.2 geht, wäre die ausgehende Route trotzdem über eth0.

[oxygen]

Ja so eine Konfiguration ist natürlich möglich. Aber hier nicht der Fall. Eine Anfrage aus dem Internet (sprich ausserhalb 10.0.0.0/8) an die VPN IP des Kunden Systems kann nicht über die VPN Verbindung beantwortet werden.

[Joe User]

Ich habe momentan leider nur ein Netz zur Verfügung, aber das Setzen eines zweiten Gateways funktioniert wie ich bereits vermutete:

Code: Select all

gentoo ~ # cat /etc/conf.d/net
config_eth0=( "192.168.178.7/24 brd 192.168.178.255" )
routes_eth0=(
        "10.0.0.7 via 192.168.178.1"
        "default via 192.168.178.1"
)
gentoo ~ # route -n
Kernel IP Routentabelle
Ziel            Router          Genmask         Flags Metric Ref    Use Iface
10.0.0.7        192.168.178.1   255.255.255.255 UGH   0      0        0 eth0
192.168.178.0   0.0.0.0         255.255.255.0   U     0      0        0 eth0
127.0.0.0       0.0.0.0         255.0.0.0       U     0      0        0 lo
0.0.0.0         192.168.178.1   0.0.0.0         UG    0      0        0 eth0
gentoo ~ #

Da die zweite Route (VPN) zuerst in der Routing-Table steht, wird auch das damit verknüpfte Gateway benutzt. Wie der OP das jetzt in seiner Distribution umsetzt, ist nicht mein Problem

EDIT: Um es deutlicher zu machen:

Code: Select all

gentoo ~ # cat /etc/conf.d/net
config_eth0=(
        "10.0.0.7/24 brd 10.0.0.255"
        "192.168.178.7/24 brd 192.168.178.255"
)
routes_eth0=(
        "10.0.0.7 via 10.0.0.1"
        "default via 192.168.178.1"
)
gentoo ~ # route -n
Kernel IP Routentabelle
Ziel            Router          Genmask         Flags Metric Ref    Use Iface
10.0.0.7        10.0.0.1        255.255.255.255 UGH   0      0        0 eth0
192.168.178.0   0.0.0.0         255.255.255.0   U     0      0        0 eth0
10.0.0.0        0.0.0.0         255.255.255.0   U     0      0        0 eth0
127.0.0.0       0.0.0.0         255.0.0.0       U     0      0        0 lo
0.0.0.0         192.168.178.1   0.0.0.0         UG    0      0        0 eth0
gentoo ~ #

[captaincrunch]

Lieber matzew: Es geht hier (so weit ich das verstehe) nicht um eine DSL-Leitung, und auch nicht um billge DSL-Router.
Sobald Server A eine öffentliche IP auf Server B "durchschleust", ändert sich die Source-IP des Clients nicht. Da dieser (so weit ich das verstehe) irgendwo aus dem Internet kommen soll, wird Server B für das Antwortpaket definitiv nicht zurück übers VPN, sondern über sein Default-Gateway routen; es sei denn, du trägst die weltweiten Netze passend auf der Kiste ein. Alles andere heißt asynchrones Routing, und das ist defintiv Bäh, und führt eher früher als später zu Problemen.

Abhilfe schafft hier höchstens Policy-Routing:
Somit müsste Server B alles, was via Tunnel von Server A reinkommt auch über den Tunnel zurückschicken. Die Lektüre von lartc.org könnte daher massiv weiter helfen, als Idee sei http://lartc.org/howto/lartc.rpdb.html# ... PDB.SIMPLE genannt.

[captaincrunch]

Sofern Host A massiv in beide Richtungen nattet, hast du natürlich recht. Dieses kleine Zauberwörtchen erwähnst du im letzten Beitrag jedoch zum ersten Mal. Darüber hinaus ging es bei der Frage ums Routing.