☰

Proxy (Weiterleitungsproxy)

tag-icon • tag-icon networking docker proxy openvpn testing
Proxy (Weiterleitungsproxy)

Ich bin neu im Netzwerkbereich und probiere dies daher zum ersten Mal aus. Ich habe einen OpenVPN-Docker erstellt, der eine Verbindung zu einem VPN-Server herstellt. Die Ausführung wget -q -O - https://api.myip.cominnerhalb des Docker-Containers bestätigt, dass das Netzwerk des Dockers ordnungsgemäß mit dem VPN verbunden ist und dass die IP die des VPN-Servers ist. Jetzt möchte ich versuchen, den Host-Verkehr durch den Docker-Container zu leiten und dasselbe Ergebnis außerhalb des Containers zu erzielen, wo der Host-Verkehr die VPN-Verbindung des Dockers verwendet. Mir ist nicht ganz klar, wie ich dies über eine Docker-Host-<->-Container-Beziehung erreichen soll, daher dachte ich, ich könnte vielleicht die Port-Mapping-Funktion in Docker nutzen und auch einen Webproxy im Docker einrichten, um alle HTTP/HTTPS-Anfragen zu verarbeiten.

Daher habe ich Squid und OpenVPN-Server im selben Docker eingerichtet und Port 3128 freigegeben (da Squid dort lauscht). Der wget-Befehl auf dem Host lautet: wget -q -O - https://api.myip.com -e use_proxy=yes -e http_proxy=localhost:12345

Die Tests zeigen jedoch, dass der Datenverkehr nicht über die VPN-Verbindung des Dockers läuft. Stattdessen zeigen die Ergebnisse, dass die Kommunikation über die Internetverbindung des Hosts erfolgt.

Ich führe den Container mit dem folgenden Docker-Run-Befehl aus:

docker run --rm --cap-add NET_ADMIN --device /dev/net/tun --name vpn -it --sysctl net.ipv6.conf.all.disable_ipv6=0 -p 12345:3128 vpn-image

Ist der obige Ansatz falsch? Was ist der beste Ansatz, um Host-Verkehr über mehrere Docker-VPN-Verbindungen zu leiten?

Die folgenden Ressourcen zeigen, dass dies möglich ist, bieten aber eigene, auf ihren Anwendungsfall zugeschnittene Lösungen an. Es wäre schön, ein Linux-Netzwerktool wie wget oder curl zu haben, das mir beim Debuggen/Testen des Fortschritts meiner Lösung helfen könnte.

Antwort1

Dies ist eine alte Frage, aber sie scheint in letzter Zeit zumindest etwas Verkehr hervorgerufen zu haben, deshalb werde ich sie beantworten.

Je nachdem, was Sie versuchen, gibt es zwei Möglichkeiten, Ihr Netzwerk über das VPN laufen zu lassen, und je nachdem, was Sie weiterleiten möchten, gibt es drei Möglichkeiten, dies zu erreichen.

Proxy (Weiterleitungsproxy)

Dies erfordert, dass Ihr Hostsystem oder Container, für den Sie das VPN verwenden möchten, seinen Datenverkehr explizit an einen Proxy weiterleitet, der im VPN-Container ausgeführt wird. Ihr VPN-Container muss sowohl einen Proxy als auch das aktive VPN ausführen. Dies verwaltet die bidirektionale Netzwerkweiterleitung ziemlich effektiv.

Bei dieser Technik müssen Sie einen Port des Proxyservers des Containers freigeben, den Sie manuell im VPN-Container konfiguriert haben, und dann Ihr Hostsystem so konfigurieren, dass es localhost:portals Proxy verwendet wird. Dies ist ziemlich kompliziert und bietet viele Optionen, Sie sollten also gezielt danach googeln.

Direkte Netzwerk-Stack-Steuerung (des Hosts)

Normalerweise verfügt der VPN-Container über einen separaten Netzwerkstapel, der in einem separaten Namespace ausgeführt wird. Sie können Docker jedoch anweisen, den Netzwerk-Namespace nicht zu trennen und ihm vollen Netzwerkstapelzugriff zu gewähren, als würde er nativ auf dem Host ausgeführt. Wenn Sie versuchen, ein containerisiertes VPN so zu verwenden, als wäre es nativ auf dem Host installiert, würden Sie Folgendes tun. Die Kontrolle über den Netzwerk-Namespace des Hosts ist jedoch eine andere Berechtigung als die einfache Freigabe, daher müssen Sie auch einige Funktionen hinzufügen. Die 3xact-Funktionen hängen von Ihrer VPN-Software ab, sind jedoch normalerweise CAP_NET, CAP_NET_RAWund oft CAP_ADMIN. Wenn Sie sich nicht sicher sind und Ihrer Anwendung vertrauen, können Sie einfach den privilegierten Modus verwenden, um alle Funktionen (plus einige andere unnötige Extras) zu gewähren. Fügen Sie dazu Ihrem Run-Befehl diese beiden Optionen hinzu: --net=host --cap=CAP_NET,CAP_NET_RAW,CAP_NET_ADMIN.

Direkte Netzwerk-Stack-Steuerung (eines anderen Containers)

Diese Option basiert auf demselben Konzept wie die direkte Netzwerkstapelsteuerung des Hosts, ermöglicht jedoch die Verwendung Ihres VPN durch einen anderen Container anstelle des Hosts, als ob es innerhalb dieses Containers ausgeführt würde. Um diese Option zu verwenden, müssen Sie dem Ausführungsbefehl des Nicht-VPN-Containers nur eine Zeile hinzufügen, um ihn anzuweisen, den Netzwerkstapel mit Ihrem VPN-Container zu teilen:--net=container:vpn-container-name

verwandte Informationen