En quelques mots, je souhaiterai n’avoir qu’une seule adresse IP visible, ça serai celle du serveur s’occupant de router les ports vers les différentes autres machines sans que les adresses IP de ces autres machines soient visibles.
J’ai essayé plusieurs manipulations avec iptables pour faire le routage des ports mais sans succès.
Auriez-vous une solution à me proposer, des trucs à essayer ?
1/ Les adresses IP de tes serveurs ne sont plus cachés puissent que tu viens de les communiquer
2/ Ton architecture est viable cependant pour le besoin décrit, il t’est inutile d’avoir des IP failover (payante), un plan d’adressage privé (192.168.x.x/24) répondra à ton besoin.
3/ Concernant le principe de port forwarding, un simple iptables (sur le serveur 37.59.234.55) avec des règles de ce style suffit : http://www.croc-informatique.fr/2009/10/redirection-de-port-ou-port-forwarding-avec-iptables/
4/ Ne crois pas améliorer la sécurité de tes serveurs cachés en procédant ainsi
1/ Ce sont des adresses IP fictives
2/ Comment mettre en place ce plan d’adressage IP sur deux serveurs dédiés de deux réseaux différents ?
3/ Je cours essayer ça tout de suite
4/ Rien à dire x)
Proxy/relais de port
Reverse proxy pour HTTP, n’importe quel relais de port (stunnel, socat, stone, sslwrap, rinetd, redir, 6tunnel, simpleproxy…) pour les protocoles quelconques.
Avantage : simplicité.
Inconvénient : le serveur caché ne voit pas l’adresse IP source du client mais celle du proxy/relais (exception avec un reverse proxy HTTP qui peut passer l’adresse source originelle dans un en-tête de type X-Fowarded-For). Cela peut être gênant pour les logs, contrôle d’accès… On peut éventuellement gérer les logs et l’accès du côté du relais, mais c’est plus compliqué et limité.
Redirection DNAT (NAT destination) avec iptables
Les règles DNAT ne sont pas suffisantes. Une contrainte est que le trafic retour doit repasser par le serveur frontal pour être “dé-NATé” avant de repartir vers le client. D’autre part les équipements réseau de l’hébergeur pourraient avoir des filtres bloquant les paquets émis avec une autre adresse IP source que celle de la machine émettrice. Deux solutions à cela :
2a) Une règle iptables SNAT (NAT source) qui remplace l’adresse source des connexions redirigées par l’adresse du serveur frontal.
Avantage : relative simplicité.
Inconvénient : le même que la solution 1).
2b) Un tunnel IP entre le serveur frontal et chaque serveur caché (VPN ou simple tunnel IPIP, pas besoin de chiffrement ni d’authentification puisque le trafic et public) et du routage avancé pour que le trafic retour des serveurs cachés passe dans le tunnel.
Avantage : les serveurs cachés voient l’adresse source du client.
Inconvénient : complexité.
@ PascalHambourg : En effet, la solution 2b me semble plus appropriée. J’avais également tenté la 2a et effectivement, les clients avaient l’adresse IP du serveur où les règles IPTABLES avaient été appliquées. Avec un VPN PPTP ça passerai sans soucis ?
J’allais t’aider à mettre en œuvre la solution 2 + 2a mais à la vue de ton serveur dedibox, je te recommande la mise en œuvre d’un VPN.
A noter qu’en faisant ça tu vas rediriger toutes tes requêtes du port 9987 (teamspeak si google ne se trompe pas ) vers le serveur OVH puis vers le serveur dedibox. Quel en est l’utilité ?
Sans soucis, pas sûr…
VPN PPTP pourquoi pas, ou openvpn, vtun, tunnel IP d’openssh (ssh -w), tunnel IPIP ou GRE avec la commande “ip tunnel”… le choix est vaste.
Ensuite il y a deux variantes.
a) On affecte des adresses privées aux extrémités des tunnels et on fait les redirections vers ces adresses privées. Ainsi le routage est plus simple à faire :
dans le sens frontal -> serveur caché, routage standard basé sur l’adresse de destination (privée) ;
dans le sens retour serveur caché -> frontal, routage avancé basé sur l’adresse source (ip rule from + table de routage alternative avec une route par défaut via le tunnel).
b) On n’affecte pas d’adresses privées aux tunnels, on utilise donc les adresses publiques des serveurs cachés même dans les tunnels. Mais le routage est plus compliqué :
dans le sens frontal -> serveur caché, marquage par iptables des paquets à router par le tunnel et routage avancé basé sur la marque d’iptables (ip rule fwmark) ;
dans le sens retour serveur caché -> frontal, même chose. Pour identifier les paquets à marquer avec iptables, on peut soit utiliser le port source (uniquement si le serveur ne reçoit pas de connexions en direct), soit marquer les connexions entrant par le tunnel avec -j CONNMARK et identifier les paquets retour avec -m connmark.
Dans les deux cas, vérifier que la validation d’adresse source par reverse path filtering (rp_filter=0) est désactivée sur les interfaces ethernet et tunnel des machines.
Je ne détaille pas parce que je ne vais quand même pas faire tout le boulot, mais je peux aider sur un point particulier en cas de difficulté.
Le problème de la solution 2a est que sur TeamSpeak (par exemple), je ne verrai pas la véritable adresse IP du client mais celle du serveur faisant office de proxy.
L’utilité de ce système est que je n’aurai plus à gérer les paramètres réseaux de chacun de mes serveurs (règles iptables par exemples) mais d’un seul. N’utilisant pas beaucoup de bande passante sur la totalité de mon infrastructure, le débit ne posera pas de problèmes. De plus, j’ai rencontré des problèmes d’interconnexion entre certains de mes clients et mes hébergeurs (récemment Orange <=> Online). Avec OVH, je n’ai pour l’instant pas eu ce genre de soucis (en tout cas, ça ne s’est pas vu). Donc si ils passent par le tunnel du serveur frontal, ils ne rencontreront plus ce problème puisque que je n’ai jamais eu de soucis d’interconnexion entre les hébergeurs.
Par contre j’ai une autre question dont je pense avoir la réponse. Si le serveur frontal se fait attaquer (ou vient à saturer), la totalité de mes services seront indisponibles. C’est ça ?
En fait mon problème n’est pas entièrement résolu…
J’ai configuré un tunnel vtun entre mes deux machines.
176.31.205.38 est le serveur frontal (alias 10.0.0.1)
37.59.207.127 est le serveur web (alias 10.0.0.2)
J’ai donc lancé ces deux règles iptables
iptables -t nat -A PREROUTING -d 176.31.205.38 -p tcp --dport 80 -j DNAT --to-dest 10.0.0.2:80
iptables -t nat -A POSTROUTING -d 10.0.0.2 -p tcp --dport 80 -j SNAT --to 176.31.205.38
sur le serveur frontal pour que le serveur web soit accessible via 176.31.205.38/. Malheureusement, il ne l’est pas. Ai-je zappé quelque chose ?
[quote=“Energeek”]176.31.205.38 est le serveur frontal (alias 10.0.0.1)
37.59.207.127 est le serveur web (alias 10.0.0.2)[/quote]
Alias ? Tu veux dire que 176.31.205.38 et 37.59.207.127 sont les adresses publiques, et 10.0.0.1 et 10.0.0.2 sont les adresses privées configurées à chaque extrémité du tunnel ?
Pourquoi la règle SNAT ? C’est utile seulement pour la méthode 2a) qui ne nécessite pas de tunnel.
Que se passe-t-il exactement ?
Tu as vérifié les interfaces, la table de routage et les règles iptables sur les deux machines, ip_forward=1 sur le frontal, examiné le trafic sur chaque extrémité du tunnel avec un outil de capture de paquets comme tcpdump ?
[quote=“PascalHambourg”][quote=“Energeek”]176.31.205.38 est le serveur frontal (alias 10.0.0.1)
37.59.207.127 est le serveur web (alias 10.0.0.2)[/quote]
Alias ? Tu veux dire que 176.31.205.38 et 37.59.207.127 sont les adresses publiques, et 10.0.0.1 et 10.0.0.2 sont les adresses privées configurées à chaque extrémité du tunnel ?[/quote]
Oui, c’est ça.
Pourquoi la règle SNAT ? C’est utile seulement pour la méthode 2a) qui ne nécessite pas de tunnel.[/quote]
D’acc. Quelles règles dois-je utiliser dans ce cas là ?
Que se passe-t-il exactement ?
Tu as vérifié les interfaces, la table de routage et les règles iptables sur les deux machines, ip_forward=1 sur le frontal, examiné le trafic sur chaque extrémité du tunnel avec un outil de capture de paquets comme tcpdump ?[/quote]
Dans /etc/sysctl.conf : net.ipv4.ip_forward=1 donc c’est bon.
Les interfaces sont OK, les adresses privées se ping correctement.
Aucun règles IPTABLES n’est active de base.
tcpdump ne m’affiche rien, juste des infos concernant ma connexion en SSH
J’ai expliqué le principe dans mes messages précédents, sans entrer dans les détails. Néanmoins tu peux utiliser la règle SNAT dans un premier temps pour valider le fonctionnement de la redirection avec le tunnel. Dans un second temps, tu pourras mettre en place le routage avancé pour les paquets retour sur le serveur caché.
Oui mais non : il faut vérifier directement dans le noyau avec sysctl.
Il faut dire à tcpdump de ne pas capturer le trafic SSH (not port 22) pour éviter que le trafic utile soit noyé dans le bruit lorsque tu fais un essai. Sur quelle interface tu l’as fait écouter ? Sur l’interface ethernet, il devrait voir les paquets échangés avec l’extérieur et notamment les paquets encapsulant le tunnel. Sur l’interface tun, il devrait voir les paquets encapsulés dans le tunnel. Tu peux commencer par vérifier que tcpdump affiche bien les paquets avec un ping des adresses privées.
Ma question va être un peu HS mais bon…
J’ai vu je ne sais plus où qu’il y a des solutions qui permettent justement de ne pas passer par le frontal en retour. Grosso modo : client -> frontal -> back-end -> client.
J’ai pas assez de connaissances en réseau pour comprendre comment ça pourrait marcher, mais le fait est qu’il y a au moins un produit (que je n’arrive pas à retrouver) qui permet ça. Une idée du processus, au niveau réseau ? Je suppose que ça doit impliquer une sorte de spoofing d’adresse…
Pour Linux, il y a notamment IPVS (http://www.linuxvirtualserver.org/) qui est initialement prévu pour faire de la répartition de charge avec plusieurs serveurs cachés derrière une machine servant de répartiteur. A voir si ça ne pourrait pas répondre au besoin, d’ailleurs… Je ne connais pas particulièrement.
) vers le serveur OVH puis vers le serveur dedibox. Quel en est l’utilité ?
et non pas dans le titre du sujet… 
