Forum Linux.débutant redirection de port NAT à travers OpenVPN

Posté par Thx le 29 décembre 2020 à 22:09. Licence CC By‑SA.

Étiquettes :

déc.

2020

Bonjour

Il y a 15 ans de ça j'étais au top sur iptables, mais 15 ans sans avoir besoin d'y bidouiller ont eu raison de mon neurone, alors : À L'AIDE ! ;-)

Je vous explique mon problème :
J'ai un FAI qui fait du partage d'IP v4, et biensûr il est impossible d'ouvrir un port. Cependant, j'aimerai pouvoir me connecter sur mon raspbery PI qui est à la maison depuis mon téléphone, où que je me trouve.

Ma solution :
Ayant un serveur hébergé en datacenter (disons eth0:213.36.253.176), j'ai donc mis en place un OpenVPN (j'ai essayé en TUN et en TAP) entre les deux machines (192.168.15.1 pour le serveur et 192.168.15.2 pour le RPI) et essayé de faire du NAT pour que le port 34080 du serveur arrive sur le port 80 du RPI.

Forcément, si je suis ici, c'est que ça ne fonctionne pas. OpenVPN c'est bon, ça marche, depuis le serveur j'arrive à me connecter au port 80 du RPI. Par contre, le NAT, à défaut de mémoire longue durée dans mon cerveau, j'ai suivi une dizaine de tutos et je n'arrive pas à mettre en place la redirection de port. J'ajoute mes règles, mais le port 34080 reste fermé sur le serveur.

Voilà une des solutions que j'ai essayées :

echo 1 > /proc/sys/net/ipv4/ip_forward
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 34080 -j DNAT --to-destination 192.168.15.2:80
iptables -A FORWARD -i eth0 -p tcp --dport 80 -j ACCEPT

Note : je n'ai aucune règle iptables initialement : je part d'une situation propre pour ne pas avoir d'interférences.

Merci d'avance pour votre aide !

Thierry

# changer de FAI

Posté par NeoX le 29 décembre 2020 à 22:59. Évalué à 2.

ou si le FAI le permet (free par exemple)
aller dans les paramètres de ton compte et demander une 'IP full stack' pour voir tous les ports disponibles

sinon pour ton NAT, il faut encore que le RPi répondent par le VPn pour un client qui arrive du VPN

le plus simple ca reste le MASQUERADE pour les flux -i tun0
# Ou proxy ?

Posté par monsieurw le 30 décembre 2020 à 00:20. Évalué à 4.

Hello

Je ne réponds pas à la question, mais j'ai eu un besoin de ce genre, et je ne suis pas à l'aise avec IPTables quand il y a des VPN, NAT et autres redirections.

J'ai installé en frontal un HaProxy et hop : même pas besoin de port supplémentaire, la redirection se faisait selon l'URL. La restriction cependant, c'était uniquement des services Web (quoiqu'il soit possible de "proxyfier" d'autres services).
- [^] # Re: Ou proxy ?
  
  Posté par Thx le 30 décembre 2020 à 08:25. Évalué à 2. Dernière modification le 30 décembre 2020 à 08:25.
  
  C'est une bonne idée également. En réalité j'ai 2 services à ouvrir : SSH et HTTPS. Si je ne m'en sors pas avec iptables, j'approfondirai cette proposition.
# Proposition de règles iptables

Posté par root_rtfm le 30 décembre 2020 à 06:42. Évalué à 3.
Bonjour,

La connexion se faisant sur le serveur hébergé, il ne me semble pas nécessaire de translater le port, ce serveur a accès à tout les ports de 0 à 65535, contrairement à celui derrière la box. Aussi, il me semble qu'une règle de NAT du serveur hébergé vers le RPi via le vpn devrait suffire, en convervant le port …
```
 /usr/sbin/iptables -v -t nat -A PREROUTING -i eth0 -p tcp -s 0.0.0.0/0 -d 0.0.0.0/0 -m multiport --dports 80 --j DNAT --to-destination 192.168.15.2
 /usr/sbin/iptables -v -A FORWARD -i eth0 -o tap0 -p tcp -s 0.0.0.0/0 --sport 1024:65535 -m conntrack --ctstate NEW,ESTABLISHED -m multiport -d 192.168.15.2 --dports 80 -j nologaccfw
 /usr/sbin/iptables -v -A FORWARD -i tap0 -o eth0 -p tcp -m multiport -s 192.168.15.1 --sports 80 -m conntrack --ctstate ESTABLISHED -d 0.0.0.0/0 -j nologaccfw
```
En dupliquant 3 fois la règle et en remplaçant le port 80 par les bloques 0:21, 23:1193, et 1194:65535, toutes les connexions arrivant sur le serveur hébergé sauf celles du vpn et du ssh, seront redirigées sur le Rpi, par contre il faut peut-être mettre quelques règles iptables sur le Rpi pour le protéger un minimum…

Good Luck ;-)
- [^] # Re: Proposition de règles iptables
  
  Posté par Thx le 30 décembre 2020 à 08:45. Évalué à 2. Dernière modification le 30 décembre 2020 à 08:46.
  Merci pour ta proposition.
  
  Je ne veux fournir que 2 services : HTTP/HTTPS et SSH donc je ne vais pas forwarder tous les ports. Pour commencer je me fais la main sur HTTP (que je supprimerai probablement à terme).
  Pour ce qui est de la translation, j'en ai besoin car mon serveur hébergé propose déjà ses propres services HTTP/HTTPS/SSH.
  
  Est-ce que tu peux corriger ma compréhension de ta proposition :
```
 /usr/sbin/iptables -v -t nat -A PREROUTING -i eth0 -p tcp -s 0.0.0.0/0 -d 0.0.0.0/0 -m multiport --dports 80 --j DNAT --to-destination 192.168.15.2
```
  ==> tout ce qui arrive sur eth0 en TCP, quel que soit le client (-s 0.0.0.0/0 => utile à préciser ?) et quelle que soit l'ip assignée à eth0 (-d 0.0.0.0/0) sur le port 80 (-m multiport --dports 80 => je dois donc remplacer par 34080 => quelle est la différence avec --dport 80 ?) doit déclencher une règne DNAT et être addressé à mon RPI (--to-destination 192.168.15.2 => de dois donc préciser le port 80 pour faire la translation)
```
 /usr/sbin/iptables -v -A FORWARD -i eth0 -o tap0 -p tcp -s 0.0.0.0/0 --sport 1024:65535 -m conntrack --ctstate NEW,ESTABLISHED -m multiport -d 192.168.15.2 --dports 80 -j nologaccfw
```
  ==> autoriser le forward des paquets arrivant par eth0 et ressortant par tap0 (le VPN), en TCP, quelle qu'en soit l'origine depuis un port compris entre 1024 et 65535 (pourquoi limiter ?), effectuer un suivi des connexions (conntrack => pour gérer les états NEW/ESTABLISHED je suppose, et pouvoir ré-adresser les réponses à la bonne source), à destination du RPI sur le port 80. sans log
```
 /usr/sbin/iptables -v -A FORWARD -i tap0 -o eth0 -p tcp -m multiport -s 192.168.15.1 --sports 80 -m conntrack --ctstate ESTABLISHED -d 0.0.0.0/0 -j nologaccfw
```
  ==> sens contraire : autoriser le forward des paquets arrivant de tap0 et ressortant par eth0, dont l'origine est [le serveur ? ça ne devrait pas être l'ip du RPI plutôt ?], port 80 et correspondant à une connexion déjà établie
  
  Merci d'avance pour les éclaircissements :-)
  - [^] # Re: Proposition de règles iptables
    
    Posté par root_rtfm le 30 décembre 2020 à 13:24. Évalué à 2.
    De rien, ;-)
    
    Les règles peuvent être simplifiées, je les ai extraites de ma configuration qui est un peu plus longue et utilise des scripts d'environs 10 ans ;-)
    - Tout ce qui rentre sur le port 34080 sur le serveur hébergé est renvoyé sur le Rpi sur le port 80, quelque soit la source et la destination
    /usr/sbin/iptables -v -t nat -A PREROUTING -i eth0 -p tcp -s 0.0.0.0/0 -d 0.0.0.0/0 -m multiport --dports 34080 --j DNAT --to-destination 192.168.15.2:80
    
    Les états sont effectivement gérés, est-ce toujours utile de nos jours ? normalement, une connexion n'est sensé sortir dans ce sens si elle n'a pas été initié ….
    - Forward tout ce qui est a destination du 34080 sur le 80 du Rpi, le port source car en théorie, le port source d'une connexion ne peut pas être réservé, donc au-dessus de 1024, mais ce n'est pas indispensable.
    /usr/sbin/iptables -v -A FORWARD -i eth0 -o tap0 -p tcp -s 0.0.0.0/0 --sport 1024:65535 -m conntrack --ctstate NEW,ESTABLISHED -m multiport -d 192.168.15.2 --dports 34080 -j nologaccfw
    - Oui, il y bien une erreur dans l'adresse source … dsl,
    /usr/sbin/iptables -v -A FORWARD -i tap0 -o eth0 -p tcp -m multiport -s 192.168.15.2 --sports 34080 -m conntrack --ctstate ESTABLISHED -d 0.0.0.0/0 -j nologaccfw
    
    Et j'ai oublié de préciser que le nologaccfw correspond à
    /usr/sbin/iptables -v -N nologaccfw
    /usr/sbin/iptables -v -A nologaccfw -j ACCEPT
    
    Je ne suis pas sûr d'être clair ….
    - [^] # Re: Proposition de règles iptables
      
      Posté par Thx le 30 décembre 2020 à 22:24. Évalué à 1.
      
      Si si tu es clair, de toutes facons, j'ai toujours RTFM pour m'aider ! :-)
      
      Par contre ça ne fonctionne pas …
      
      … mais Silmaril à la solution (voir le dernier commentaire)
      
      Merci quand même, c'est bien gentil de m'avoir offert ton temps !
# tun0

Posté par gUI (Mastodon) le 30 décembre 2020 à 08:11. Évalué à 1. Dernière modification le 30 décembre 2020 à 08:12.

Je suis loin d'être spécialiste iptables, mais quand je vois tes règles je ne vois nulle-part apparaître tun0 (ou tap0 selon ta config OpenVPN). C'est sous contrôle ?

En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
- [^] # Re: tun0
  
  Posté par Thx le 30 décembre 2020 à 08:26. Évalué à 1.
  
  Comme je disais, j'ai gravement perdu en connaissances d'iptables, donc ce que j'ai fait n'est pas très réfléchi et très copié-collé :(
# Problème sur le nat de la source

Posté par -=[ silmaril ]=- (site web personnel) le 30 décembre 2020 à 14:38. Évalué à 5.
Ta seule erreur est sur le POSTROUTING:
ce sont les packets à destination de ton interface VPN + ip rpi qu'il faut source-nater pour que le retour tcp passe bien par ton serveur et pas en direct sur la route par defaut du rpi2.

il faut donc modifier le MASQUERADE pour un "-o tun0" ou "-o tap0" selon l'interface construite par openvpn
```
iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE
```
- [^] # Re: Problème sur le nat de la source
  
  Posté par Thx le 30 décembre 2020 à 22:21. Évalué à 2.
  
  Yes ! ça marche ! :D Merci !!!
# Commentaire supprimé

Posté par Anonyme le 31 décembre 2020 à 12:53. Évalué à 2.

Ce commentaire a été supprimé par l’équipe de modération.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.