VirtualBox-VPN-Gateway für das LAN: Bridge, Route, Rückweg

Entfernte Benutzer müssen einen Drucker und einen Dateiserver in einem physischen LAN erreichen, und die einzige ständig laufende Linux-Kiste ist eine VirtualBox-VM. Die VM per Bridge in dieses LAN zu hängen, ist die erste Hälfte. Die zweite Hälfte ist eine Rückroute, die jedes Gerät im LAN tatsächlich benutzt, und genau das übersehen die meisten Setups. Fehlt sie, kommt der Tunnel zustande, der Client pingt das Gateway, und nichts anderes antwortet.

Verwenden Sie erreichbare Adressen

Stellen Sie den LAN-Adapter der VM auf die für dieses Netz freigegebene Bridged-Adapter-Anbindung und geben Sie ihr über den normalen Zuweisungsprozess eine Adresse. Dann erscheint die VM im physischen LAN wie jeder andere Host. Ihre Standardroute muss weiterhin das echte Gateway nutzen, damit der verschlüsselte Transport zum VPN-Peer erreichbar bleibt. Verwenden Sie nicht die Standard-NAT-Adresse von VirtualBox als nächsten Hop für das LAN, denn diese Adresse liegt hinter einem virtuellen NAT und ist weder für den Host noch für andere LAN-Rechner on-link.

LAN router:          192.168.70.1/24
VirtualBox host:     192.168.70.5/24
VPN gateway VM:      192.168.70.10/24
Example LAN service: 192.168.70.40
VPN client pool:     10.80.0.0/24

Prüfen Sie vor der Wahl des Pools auf Überschneidungen mit den Heimnetzen der entfernten Benutzer. Eine Überschneidung wird zu einer Routing-Mehrdeutigkeit, die keine Serverkonfiguration behebt.

Kündigen Sie das LAN an, dann leiten Sie weiter

Für einen Server, dessen Authentifizierung und Transport bereits verwaltet werden, sehen die Netzwerkzeilen so aus. Der Push sagt einem annehmenden Client, wie er das LAN erreicht, und er veranlasst die VM nicht von sich aus, irgendetwas weiterzuleiten.

dev tun
topology subnet
server 10.80.0.0 255.255.255.0
push "route 192.168.70.0 255.255.255.0"

Aktivieren Sie die IPv4-Weiterleitung in der persistenten Netzwerkkonfiguration der VM und erlauben Sie dem Client-Pool, die vorgesehenen LAN-Dienste an der Weiterleitungsgrenze der VM zu erreichen. Die Erlaubnis, den VPN-Listener zu erreichen, ist eine eigene Regel, und sie funktioniert bereits, wenn der Tunnel hochkam.

Die Rückroute gehört auf den LAN-Router

LAN-Geräte antworten über ihr Standardgateway, also den LAN-Router unter 192.168.70.1. Dieser Router weiß nicht, wo 10.80.0.0/24 liegt, solange man es ihm nicht sagt. Fügen Sie die Pool-Route in die unterstützte persistente Konfiguration des Routers ein und zeigen Sie auf die LAN-Adresse der VM. Sie nur auf dem VirtualBox-Host einzutragen repariert Pfade, die diesen Host fragen, und das ist nicht jedes Gerät im LAN.

ip route add 10.80.0.0/24 via 192.168.70.10

Die Firewall des Ziels muss den Client-Pool weiterhin als Quelle zulassen. Eine Route trägt das Paket; sie gewährt nicht den Dienst.

Kann der LAN-Router nicht geändert werden, ist begrenzte Quellübersetzung auf der VM die Alternative. Sie lässt Antworten ohne die Route zurückkommen und verbirgt die einzelnen Client-Adressen vor dem LAN-Dienst.

Verfolgen Sie ein Paket von Ende zu Ende

Ein Client unter 10.80.0.25 sendet über den Tunnel an 192.168.70.40. Die VM leitet das Paket in das LAN weiter. Der Dienst antwortet an seinen Router, der die VM für den Client-Pool auswählt, und die VM schickt das Paket über OpenVPN zurück. Jeder Hop in diesem Satz ist eine Stelle, an der das Design scheitern kann.

Testen Sie mit der echten Anwendung von einem entfernten Client und wiederholen Sie den Test, nachdem Sie die verwaltete Konfiguration sowohl auf der VM als auch auf dem Router neu geladen haben.

Wenn der Client die VM, aber nicht den Dienst erreicht, prüfen Sie zuerst die Route des Routers. Wenn der Dienst die Anfrage erhält und der Client nie die Antwort sieht, ist der Rückweg der Verdächtige.