J'ai pu mettre en place un espace de noms réseau, établir un tunnel avec openvpn et démarrer une application qui utilise ce tunnel à l'intérieur de l'espace de noms. Jusqu'ici tout va bien, mais cette application est accessible via une interface Web et je n'arrive pas à comprendre comment acheminer les demandes vers l'interface Web à l'intérieur de mon réseau local.
J'ai suivi un guide de @schnouki expliquant comment configurer un espace de noms réseau et exécuter OpenVPN à l'intérieur de celui-ci
ip netns add myvpn
ip netns exec myvpn ip addr add 127.0.0.1/8 dev lo
ip netns exec myvpn ip link set lo up
ip link add vpn0 type veth peer name vpn1
ip link set vpn0 up
ip link set vpn1 netns myvpn up
ip addr add 10.200.200.1/24 dev vpn0
ip netns exec myvpn ip addr add 10.200.200.2/24 dev vpn1
ip netns exec myvpn ip route add default via 10.200.200.1 dev vpn1
iptables -A INPUT \! -i vpn0 -s 10.200.200.0/24 -j DROP
iptables -t nat -A POSTROUTING -s 10.200.200.0/24 -o en+ -j MASQUERADE
sysctl -q net.ipv4.ip_forward=1
mkdir -p /etc/netns/myvpn
echo 'nameserver 8.8.8.8' > /etc/netns/myvpn/resolv.conf
Après cela, je peux vérifier mon adresse IP externe et obtenir des résultats différents à l'intérieur et à l'extérieur de l'espace de noms, comme prévu:
curl -s ipv4.icanhazip.com
<my-isp-ip>
ip netns exec myvpn curl -s ipv4.icanhazip.com
<my-vpn-ip>
L'application est lancée, j'utilise déluge pour cet exemple. J'ai essayé plusieurs applications avec une interface web pour m'assurer que ce n'était pas un problème spécifique au déluge.
ip netns exec myvpn sudo -u <my-user> /usr/bin/deluged
ip netns exec myvpn sudo -u <my-user> /usr/bin/deluge-web -f
ps $(ip netns pids myvpn)
PID TTY STAT TIME COMMAND
1468 ? Ss 0:13 openvpn --config /etc/openvpn/myvpn/myvpn.conf
9302 ? Sl 10:10 /usr/bin/python /usr/bin/deluged
9707 ? S 0:37 /usr/bin/python /usr/bin/deluge-web -f
Je peux accéder à l'interface Web sur le port 8112 à partir de l'espace de noms et de l'extérieur si je spécifie l'ip de veth vpn1.
ip netns exec myvpn curl -Is localhost:8112 | head -1
HTTP/1.1 200 OK
ip netns exec myvpn curl -Is 10.200.200.2:8112 | head -1
HTTP/1.1 200 OK
curl -Is 10.200.200.2:8112 | head -1
HTTP/1.1 200 OK
Mais je veux rediriger le port 8112 de mon serveur vers l'application dans l'espace de noms. Le but est d'ouvrir un navigateur sur un ordinateur à l'intérieur de mon réseau local et d'obtenir l'interface Web avec http: // mon-serveur-ip: 8112 (mon-serveur-ip étant l'ip statique du serveur qui a instancié l'interface réseau)
EDIT: J'ai supprimé mes tentatives de création de règles iptables. Ce que j'essaie de faire est expliqué ci-dessus et les commandes suivantes devraient générer un HTTP 200:
curl -I localhost:8112
curl: (7) Failed to connect to localhost port 8112: Connection refused
curl -I <my-server-ip>:8112
curl: (7) Failed to connect to <my-server-ip> port 8112: Connection refused
J'ai essayé les règles DNAT et SNAT et jeté une MASQUERADE pour faire bonne mesure, mais comme je ne sais pas ce que je fais, mes tentatives sont vaines. Peut-être que quelqu'un peut m'aider à construire cette construction.
EDIT: La sortie tcpdump de tcpdump -nn -q tcp port 8112
. Sans surprise, la première commande renvoie un HTTP 200 et la deuxième commande se termine avec une connexion refusée.
curl -Is 10.200.200.2:8112 | head -1
listening on vpn0, link-type EN10MB (Ethernet), capture size 262144 bytes
IP 10.200.200.1.36208 > 10.200.200.2.8112: tcp 82
IP 10.200.200.2.8112 > 10.200.200.1.36208: tcp 145
curl -Is <my-server-ip>:8112 | head -1
listening on lo, link-type EN10MB (Ethernet), capture size 262144 bytes
IP <my-server-ip>.58228 > <my-server-ip>.8112: tcp 0
IP <my-server-ip>.8112 > <my-server-ip>.58228: tcp 0
EDIT: @schnouki lui-même m'a montré un article de l'administration Debian expliquant un proxy TCP iptables générique . Appliqué au problème en question, leur script ressemblerait à ceci:
YourIP=<my-server-ip>
YourPort=8112
TargetIP=10.200.200.2
TargetPort=8112
iptables -t nat -A PREROUTING --dst $YourIP -p tcp --dport $YourPort -j DNAT \
--to-destination $TargetIP:$TargetPort
iptables -t nat -A POSTROUTING -p tcp --dst $TargetIP --dport $TargetPort -j SNAT \
--to-source $YourIP
iptables -t nat -A OUTPUT --dst $YourIP -p tcp --dport $YourPort -j DNAT \
--to-destination $TargetIP:$TargetPort
Malheureusement, le trafic entre les interfaces veth s'est saisi et rien d'autre ne s'est produit. Cependant, @schnouki a également suggéré l'utilisation de socat
comme proxy TCP et cela fonctionne parfaitement.
curl -Is <my-server-ip>:8112 | head -1
IP 10.200.200.1.43384 > 10.200.200.2.8112: tcp 913
IP 10.200.200.2.8112 > 10.200.200.1.43384: tcp 1495
Je n'ai pas encore compris l'étrange brassage de port pendant que le trafic traverse les interfaces veth, mais mon problème est résolu maintenant.
veth
appareils (trouver cela très intéressant, cependant ... ;-)). Avez-vous utilisétcpdump
pour vérifier jusqu'où les paquets entrants arrivent? Sitcpdump -i veth0
rien ne s'affiche, celatcpdumo -i lo
peut être nécessaire.Réponses:
J'ai toujours eu des problèmes avec les redirections iptables (probablement ma faute, je suis presque sûr que c'est faisable). Mais pour un cas comme le vôtre, il est plus facile de le faire dans un pays utilisateur sans iptables.
Fondamentalement, vous devez avoir un démon dans votre espace de travail "par défaut" écoutant sur le port TCP 8112 et redirigeant tout le trafic vers le port 10.200.200.2 8112. Il s'agit donc d'un simple proxy TCP.
Voici comment le faire avec socat :
(L'
fork
option est nécessaire pour évitersocat
de s'arrêter après la fermeture de la première connexion proxy).EDIT : ajouté
reuseaddr
comme suggéré dans les commentaires.Si vous voulez absolument le faire avec iptables, il y a un guide sur le site d' administration Debian . Mais je préfère toujours
socat
des choses plus avancées - comme le proxy IPv4 en IPv6, ou le dépouillement de SSL pour permettre aux anciens programmes Java de se connecter à des services sécurisés ...Sachez cependant que toutes les connexions dans Deluge se feront à partir de l'IP de votre serveur au lieu de l'IP client réel. Si vous voulez éviter cela, vous devrez utiliser un véritable proxy inverse HTTP qui ajoute l'IP client d'origine à la demande mandatée dans un en-tête HTTP.
la source
socat
et cela accomplit exactement ce que j'essayais de faire avec iptables depuis un certain temps maintenant. J'ai testé plusieurs applications et elles fonctionnent toutes parfaitement, se connectant au monde extérieur via tun0, tout en fournissant un accès à leur interface web via veth1.reuseaddr
drapeau. Cela évite lesport already in use
erreurs lors du démarrage et de l'arrêt de socat en succession rapide:socat -4 TCP-LISTEN:8112,reuseaddr,fork TCP:10.200.200.2:8112
L'interconnexion de l'espace de noms du réseau avec l'espace de noms principal me dérange toujours. La raison pour laquelle je crée généralement un espace de noms est que je veux qu'il soit isolé. Selon ce que vous essayez de réaliser avec des espaces de noms, la création d'interconnexions peut aller à l'encontre de cet objectif.
Mais même isolé, je veux toujours le pousser sur le réseau, pour plus de commodité.
Cette solution vous permet de conserver l'isolement et de lui transmettre certaines connexions de toute façon. Vous n'avez pas besoin de créer tout ce réseau entre les deux espaces de noms de réseau juste pour transférer un port. Exécutez-le dans l'espace de noms où vous souhaitez accepter les connexions. Doit être exécuté en tant que root pour
ip netns exec
fonctionner.Il écoute les connexions dans un espace de noms réseau où vous l'exécutez, sur le port 8112, puis le client connecté
exec
s'exécuteip netns exec myvpn ...
pour exécuter le reste à l'intérieur de l'myvpn
espace de noms réseau, puis une fois à l'intérieur de l'myvpn
espace de noms réseau, il crée à nouveau une deuxième connexion avec un autresocat
.la source
:
caractères dans les guillemets simples, sinon vous pourriez rencontrer une erreur en disant... wrong number of parameters (2 instead of 1)
(2 ou 3). Sinon: fonctionne très bien! Un immense merci!Pour déluge voici ma solution. Pas besoin d'iptables. Voici les étapes:
Voila! Vous avez sécurisé déluge derrière le VPN tandis que votre déluge-web est librement accessible sur votre réseau domestique
la source
@ La réponse d'AndrDevEK est utile. Pour développer cela, vous pouvez ne pas vouloir installer
socat
. Dans ce cas, vous pouvez obtenir la même chose avec une configuration de transfert de port SSH légèrement alambiquée. En particulier, la fonction de redirection de port vers / depuis un socket de domaine unix est utile ici, car les sockets de domaine unix fonctionnent indépendamment des espaces de noms réseau:Nettoyer:
Le premier
ssh -N -L
est démarré dans l'espace de noms myvpn. Cela crée un socket de domaine Unix/tmp/myunixsock
et l'écoute. Les connexions entrantes sont transmises à localhost: 8112 (à l'intérieur de l'espace de noms myvpn). Le secondssh -N -L
est démarré dans l'espace de noms par défaut. Cela crée un port TCP d'écoute et transfère les connexions entrantes au socket de domaine unix.Il convient de noter que pour que cela fonctionne, l'
ssh
intérieur de votre espace de noms réseau devra fonctionner s'il ne l'est pas déjà (et une opération de publication sans mot de passe est utile):la source