Ich habe einen dedizierten Debian GNU/Linux-Server, der professionell gehostet wird, vollständig (remote) konfiguriert und habe eine Frage zum Netzwerk-Routing (die, soweit ich weiß, genau zu den FAQ von Serverfault passt).
Dieser dedizierte Server hat eine statische IPv4-IP und eine sehr einfache Route:
route -n
Table de routage IP du noyau
Destination Passerelle Genmask Indic Metric Ref Use Iface
94.xx.yy.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
0.0.0.0 94.xx.yy.254 0.0.0.0 UG 0 0 0 eth0
Ich habe nur eine statische IP und es gibt viele andere dedizierte Server im selben Subnetz, mit denen ich nicht herumspielen kann.
Dieser Server hostet/bedient die Haupt-Webanwendung unseres Unternehmens (Apache+Tomcat) und führt auch Squid aus. Die gesamte Konfiguration habe ich selbst vorgenommen. Sobald das Budget es zulässt, werde ich Squid auf einen anderen Server verschieben.
Vorerst möchte ich OpenVPN zu diesem Server hinzufügen (vorzugsweise mit tun, nicht mit tap) und ich möchte wissen, was getan werden muss, um sicherzustellen, dass meine Schnittstellen nicht mit den anderen dedizierten Servern „kollidieren“.
Ich verstehe nicht, wie der Aufbau erfolgen soll und bin verwirrt, wie die Route letztendlich aussehen soll.
Um mir zu helfen, das „große Ganze“ zu verstehen, könnte mir jemand ein genaues Beispiel dafür geben:
- lokale IP-Adresse eines OpenVPN-Clients
- Gateway-IP, die der OpenVPN-Client verwenden soll
- die Routenausgabe des OpenVPN-Servers
Im Grunde bin ich ein wenig ratlos und würde gerne, bevor ich anfange, verstehen, wie das Routing auf dem OpenVPN-Server erfolgt.
So wie ich das verstehe, sollen sich die OpenVPN-Clients im selben Netzwerk befinden wie der OpenVPN-Server (also beispielsweise ein 10.0.0.0/8-Netzwerk), aber ich stoße auf ein mentales Hindernis, wenn ich versuche herauszufinden, wie die Clients die „tun“-Schnittstelle verwenden sollen, um dann schließlich das Gateway 94.xx.yy.254 zu verwenden.
Antwort1
Angenommen, der VPN-Client hat die folgenden IP-Einstellungen:
IP eth0: 192.168.1.100
Default gateway: 192.168.1.1
Der gesamte nicht lokale Datenverkehr wird also über 192.168.1.1 abgewickelt. Wenn Datenverkehr zu einem anderen Host im LAN besteht, wird er nur an diesen Host weitergeleitet.
OpenVPN startet, der Client erhält eine neue Schnittstelle tun0 und dann sehen wir etwas wie:
IP eth0: 192.168.1.100
IP tun0: 10.8.0.13
Default gateway: 192.168.1.1
VPN routing: 10.8.0.1 for the network 10.8.0.0/24
Dies setzt voraus, dass der OpenVPN-Server keine zusätzlichen Routen pusht. Ein Netzwerkpaket, das beispielsweise an 8.8.8.8 geht, wird also weiterhin über das Standard-Gateway des LANs, 192.168.1.1, geleitet. Ein Paket, das beispielsweise an 10.8.0.204 geht, wird über den OpenVPN-Tunnel zum OpenVPN-Server unter 10.8.0.1 geleitet, wo es weiter geroutet wird.
Wenn der OpenVPN-Server eine Route für sein LAN pusht, sagen wir 172.16.0.0/24, dann könnte das obige VPN-Routing folgendermaßen aussehen:
VPN routing: 10.8.0.1 for the network 10.8.0.0/24
10.8.0.1 for the network 172.16.0.0/24
In ähnlicher Weise wird ein Paket für 172.16.0.24 zur weiteren Weiterleitung an 10.8.0.1 weitergeleitet.
Wenn der OpenVPN-Server die Einstellung ebenfalls pusht "redirect-gateway def1", ist das Standard-Gateway auf den VPN-Clients unterschiedlich. Sie sehen dann etwa Folgendes:
IP eth0: 192.168.1.100
IP tun0: 10.8.0.13
Default gateway: 10.8.0.1
(other gateway with lower priority): 192.168.1.1
Static route: 94.xx.yy.zz uses 192.168.1.1
Wobei 94.xx.yy.zz die öffentliche IP-Adresse Ihres OpenVPN-Servers ist.
In diesem Fall wird der Datenverkehr direkt für Ihren OpenVPN-Server über das LAN-Standardgateway 192.168.1.1 geleitet. Lokaler Datenverkehr für 192.168.1.0/24 wird wie erwartet an Hosts weitergeleitet. Jeder andere Datenverkehr verwendet 10.8.0.1; nicht lokaler Datenverkehr, der nicht direkt an die öffentliche IP des OpenVPN-Servers gerichtet ist, wird über den VPN-Tunnel geleitet und kommt aus 94.xx.yy.254.
Möglicherweise sehen Sie in der Routing-Tabelle eine andere Standardroute, die 192.168.1.1 als Gateway behält, diese hat jedoch eine geringere Priorität als 10.8.0.1. Ich denke, dies ist eher ein Platzhalter des OpenVPN-Clients, damit dieser weiß, worauf die Standardroute zurückgesetzt werden soll, sobald das VPN heruntergefahren wird. Machen Sie sich über diesen Eintrag keine Gedanken.