Il y a des experts réseaux qui te confirmeront, mais a priori, il te faut juste une seule règle DNAT dans tes iptables: iptables -t nat -A PREROUTING -p tcp --dport 80 -i [interface d’entrée] -j DNAT --to [ip de ton serveur maison sur le vpn]:80
Aprés, si ça marche, c’est une règle qui saute à chaque reboot, donc il faudra faire en sorte de déclencher ça lorsque ton vpn se connecte, et appliquer une règle inverse (la même en remplaçant le -A par un -D), pour désactiver lorsque le vpn se déconnecte.
Merci de ta réponse qui m’a permis de savoir par ou commencer
J’ai tout de même étoffé au fur et à mesure de ma compréhension du sujet
En gros (avec mes termes :D) j’autorise l’ip_forward puis je “connecte” flux entrant(eth0) et tunnel vpn puis je route les requête du port 80 vers mon serveur local
echo 1 > /proc/sys/net/ipv4/ip_forward
iptables -A FORWARD -i tun0 -o eth0 -j ACCEPT
iptables -A FORWARD -i eth0 -o tun0 -j ACCEPT
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
iptables -A INPUT -p tcp --dport 80 -j ACCEPT
iptables -t nat -A PREROUTING -p tcp --dport 80 -i tun0 -j DNAT --to 172.27.232.3
:80
Bien évidemment en l’état ça ne fonctionne pas, Il doit surement me manquer une régle ou quelquechose qui m’échappe, ou que j’ai mal compris?
Alors déjà, tu as choisi sur ton vpn des adresses en 172.27, qui sont des adresses publiques (elles peuvent être attribuées à un serveur sur le net).
La classe B privée c’est 172.16, mais à moins que tu n’aies plus de 255 machines sur ton vpn, je te conseille plutôt de choisir une classe C en 192.168.X, les fonctionnalités broadcast du réseau seront plus rapides, je crois.
J’avais oublié ça, effectivement, il faut autoriser les paquets à traverser le noyau.
Par contre, c’est plus “propre” de le faire comme ça: sysctl -w net.ipv4.ip_forward=1
Tu peux rendre ça permanent en modifiant net.ipv4.ip_forward dans /etc/sysctl.conf[quote=“b2r, post:3, topic:75632”]iptables -A FORWARD -i tun0 -o eth0 -j ACCEPT
iptables -A FORWARD -i eth0 -o tun0 -j ACCEPT[/quote]
Ca, à moins que tu n’aies défini précédemment explicitement une politique par défaut du filter/FORWARD à DROP ou REJECT, ça ne sert à rien, c’est par défaut à ACCEPT[quote=“b2r, post:3, topic:75632”]
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
[/quote]
Ca, ça ne concerne pas ce que tu veux faire, c’est une règle qui permet aux machines connectées à ton vpn d’accèder au net au travers de ton serveur vpn.
Là, c’est la bonne règle, sauf que tu lui dit de rediriger ce qui arrive sur le port 80 de ton interface vpn (tun0), c’est ce qui arrive sur eth0 qu’il faut rediriger.
Autre détail, si tu envisage de servir des sites https, pense aussi à rediriger le port 443.
Il manque peut-être encore quelque chose.
ip_forward=1 et la règle MASQUERADE sont indispensables pour que les connexions vers internet via le VPN fonctionnent. S’ils n’étaient pas déjà en place, je suppose que la route par défaut du serveur local ne passait pas via le VPN mais restait via le routeur 4G. Par conséquent les paquets de réponse seront envoyés via le routeur et non le VPN, n’auront pas la bonne adresse source en arrivant au client et les connexions échoueront. Sur le serveur local il faudrait donc router via le VPN soit des seuls paquets dont l’adresse source est celle de son interface tun (routage avancé), soit de tous les paquets (route par défaut). Ou bien MASQUERADEr les connexions redirigées par le VPS, mais cela a l’inconvénient de masquer au serveur local l’adresse IP source réelle des clients.
Apprenant qu’OpenVPN ne permet qu’une license gratuite pour deux connexions simultanés je suis contraint de changer de méthode.
En gros je vais monter un tunnel ssh entre mon serveur local et mon vps distant.
Pour rappel je souhaite accéder depuis mon VPS externe à un serveur local interne .
Le tunnel se monte bien (j’ai reparamétré arbitrairement sur le port 20000 mon apache local pour exclure un conflit sur port 80)
ssh -R 20000:127.0.0.1:20000 root@vps502***.ovh.net
Mais en essayant d’accéder à mon adresse public VPS cela ne produit rien (à part une erreur connexion échoué )
D’aprés les docs que j’épluche il n’est à priori pas nécessaire de faire de translation ou autres avec iptables.
Mes règles de filtrage sont vierges.
Avez vous une idée du problème ? J’omets quelquechose ?
Je n’ai pas fait des paramétrage quelconque coté client ssh(coté serveur local), il y a quelque chose à vérifier ?
Alors là première nouvelle. Comment tu l’as appris ?
Je n’ai jamais vérifié, mais le code source est ouvert, tout est même sous GPL, et je ne vois pas comment ils pourraient imposer ça.
Nan, ça c’est une license pour le “access serveur”, qui dispose, en plus du serveur de base disponible dans les dépots, d’une interface de config, de gestion des clés, et plein d’autoconfiguration au lieu de mettre les mains dans le cambouis des configs du serveur gpl.
C’est juste une surcouche de gestion pro qu’ils font payer, pas l’openvpn de base, si ta config de serveur fonctionne, c’est toi qui décide du nombre de clients, pas une license.
Si je fais trois connexions depuis 3 device différents, j’en ai une des 3 qui saute avec message relatif à la restriction de licence
Ou alors je pige pas un truc.
Ou bien il faut s’amuser à créer autant de users que de connexions sans passer par cette interface serveur, en mettant la main dans le camboui , puisque l’interface serveur ne le permet pas.
Là, je ne peux pas te dire, je n’ai jamais utilisé d’interface, toujours le bête paquet de base debian, et la config des fichiers à l’éditeur texte.
Aprés, ça fait des lustres que je n’ai pas eu plus de 2 clients sur mes openvpn, mais j’ai géré un Intranet openvpn avec 4 sites de prod et une dizaine de clients nomades sans probléme pendant des années.
Et encore une fois, je ne vois pas comment ils pourraient imposer ce genre de contrainte sur la version GPL, ce n’est pas compatible avec la license, et même si ça l’était, avec le code source, il suffirait de forker sans la limitation.
je suis contraint de changer de méthode.
avec message relatif à la restriction de licence