[Résolu] Redirection de port

nicolas84 · Le 13/09/2019, à 11:03

Bonjour,

Voici mon problème, je suis en train de configurer des tunnels ssh et reverse-ssh pour accéder à mes serveurs locaux depuis un serveur qui m'appartient et facilement accessible depuis le net (pare-feu que je peux ouvrir)

Depuis mon serveur, je peux accéder a ce serveur web dont j'aimerais bien accéder.
Je le vois car la commande suivante me télécharge bien index.html :

wget http://127.0.0.1:5423

Mais je ne peux accéder depuis un autre poste avec l'ip publique de ce serveur vers ce même port. (http://1.2.3.4:5423)
Le pare-feu à été ouvert mais je pense que le problème est que ce port n'est écouté par le serveur que sur l'interface lo.

Le retour de la commande netstat -tlnpu | grep 5423 :

tcp        0      0 127.0.0.1:5423          0.0.0.0:*               LISTEN      1541/ssh
tcp6       0      0 ::1:5423                :::*                    LISTEN      1541/ssh

Si je ne me trompe pas, il me faudrait une ligne 0.0.0.0:5423 pour que le serveur puisse répondre.
J'ai essayé de faire un forward port avec iptables, cela donne ça : (iptables -L -t na)

Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination
DNAT       tcp  --  anywhere             anywhere             tcp dpt:5423 to:127.0.0.1:5423

Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination
MASQUERADE  all  --  anywhere             anywhere

Je ne sais plus comment m'y prendre ni quoi chercher. Merci par avance pour votre aide !

Dernière modification par nicolas84 (Le 15/09/2019, à 08:43)

Zakhar · Le 13/09/2019, à 12:17

Il te faut Wireshark, et regarder
-1) si les paquets arrivent bien
-2) s'ils repartent au bon endroit

Si le serveur n'a pas d'interface graphique, il va falloir tracer l'équivalent avec tcpdump

La DNAT n'aide en rien dans ton cas, ce n'est pas fait pour ça !

bruno · Le 13/09/2019, à 12:31

Bonjour,

C'est franchement pas clair…
Tu as un serveur web qui n'est en écoute que sur l'interface de bouclage (lo).
Tu veux y accéder depuis l'Internet.
La solution est soit :
- reconfigurer le service web pour qu'iol soit en écoute sur toutes les interfaces ;
- configurer un hôte en reverse proxy qui renvoie sur http://127.0.0.1:5423 sur ton serveur web (Apache ou Nginx).

Je ne vois pas le rapport avec SSH ni avec tes règles de pare-feu…

nicolas84 · Le 13/09/2019, à 13:06

Bonjour,

Merci pour vos réponse.

@Zakhar
Je vais regarder du côté de tcpdump, merci

@bruno
Effectivement je n'ai pas été clair. Le serveur web n'est pas sur le serveur dont je parle...

Mon serveur web est hébergé sur un serveur chez moi (je l’appellerai serveur_local pour simplifier). Serveur_local est derrière une box 4G qui est elle-même dans un NAT que je ne peux pas configurer.
Serveur_distant est quand à lui un serveur virtualisé hébergé chez 1&1. Serveur_local ouvre un tunnel reverse-ssh vers serveur_distant pour que serveur_distant puisse ce connecter a serveur_local en ssh avec la commande ssh -p 6000 user@127.0.0.1

Ensuite, serveur_distant ouvre un tunnel ssh vers serveur_local:80 sur le port 5423. (ssh user@localhost -p 6000 -L 5423:10.0.0.210:80 -N) (10.0.0.210 est l'ip locale du serveur_local que je veux atteindre). Je peux donc ensuite m'y connecter avec serveur_distant avec http://127.0.0.1:5423

Maintenant, mon objectif est de pouvoir accéder au serveur web depuis n'importe quel poste connecté sur internet avec http://serveur_distant:5423 ou un autre port si nécessaire.

Autre précision mais qu'il ne change rien je pense, ce n'est pas vraiment un serveur web mais une application accessible via une interface web.

nicolas84 · Le 13/09/2019, à 13:22

@Zakhar

Tcpdump me sors ça en boucle sur serveur_distant lorsque je tente une connexion depuis un client quelconque : (j'ai remplacé l'ip du serveur_distant par 1.2.3.4 et l'ip du client par 5.6.7.8) :

12:17:08.073457 IP 5.6.7.8.43812 > 1.2.3.4.postgresql: Flags [.], ack 185568, win 1444, options [nop,nop,TS val 695418875 ecr 1524621836], length 0
12:17:08.073479 IP 1.2.3.4.postgresql > 5.6.7.8.43812: Flags [P.], seq 190648:190868, ack 109, win 662, options [nop,nop,TS val 1524622064 ecr 695418875], length 220
12:17:08.073489 IP 5.6.7.8.43812 > 1.2.3.4.postgresql: Flags [.], ack 186008, win 1444, options [nop,nop,TS val 695418883 ecr 1524621836], length 0
12:17:08.073493 IP 5.6.7.8.43812 > 1.2.3.4.postgresql: Flags [.], ack 186448, win 1444, options [nop,nop,TS val 695418883 ecr 1524621836], length 0
12:17:08.073601 IP 1.2.3.4.postgresql > 5.6.7.8.43812: Flags [P.], seq 190868:191568, ack 109, win 662, options [nop,nop,TS val 1524622064 ecr 695418883], length 700
12:17:08.073651 IP 1.2.3.4.postgresql > 5.6.7.8.43812: Flags [P.], seq 191568:191788, ack 109, win 662, options [nop,nop,TS val 1524622064 ecr 695418883], length 220
12:17:08.073696 IP 1.2.3.4.postgresql > 5.6.7.8.43812: Flags [P.], seq 191788:192008, ack 109, win 662, options [nop,nop,TS val 1524622064 ecr 695418883], length 220
12:17:08.073742 IP 1.2.3.4.postgresql > 5.6.7.8.43812: Flags [P.], seq 192008:192228, ack 109, win 662, options [nop,nop,TS val 1524622064 ecr 695418883], length 220
12:17:08.073785 IP 1.2.3.4.postgresql > 5.6.7.8.43812: Flags [P.], seq 192228:192448, ack 109, win 662, options [nop,nop,TS val 1524622064 ecr 695418883], length 220
12:17:08.106965 IP 5.6.7.8.43812 > 1.2.3.4.postgresql: Flags [.], ack 187208, win 1444, options [nop,nop,TS val 695418931 ecr 1524621876], length 0
12:17:08.106984 IP 1.2.3.4.postgresql > 5.6.7.8.43812: Flags [P.], seq 192448:192668, ack 109, win 662, options [nop,nop,TS val 1524622097 ecr 695418931], length 220
12:17:08.106994 IP 5.6.7.8.43812 > 1.2.3.4.postgresql: Flags [.], ack 187648, win 1444, options [nop,nop,TS val 695418931 ecr 1524621876], length 0
12:17:08.106997 IP 5.6.7.8.43812 > 1.2.3.4.postgresql: Flags [.], ack 188248, win 1444, options [nop,nop,TS val 695418967 ecr 1524621918], length 0
12:17:08.107099 IP 1.2.3.4.postgresql > 5.6.7.8.43812: Flags [P.], seq 192668:193368, ack 109, win 662, options [nop,nop,TS val 1524622097 ecr 695418967], length 700
12:17:08.107146 IP 1.2.3.4.postgresql > 5.6.7.8.43812: Flags [P.], seq 193368:193588, ack 109, win 662, options [nop,nop,TS val 1524622097 ecr 695418967], length 220

Dernière modification par nicolas84 (Le 14/09/2019, à 07:39)

bruno · Le 13/09/2019, à 13:24

Whaou, c'est quand même super tordu…

Ce serait quand même beaucoup plus simple d'héberger ton application web sur le serveur Public (celui chez 1&1).
Parce que là il va falloir en plus avoir un Apache ou un Nginx sur ton serveur_distant qui fait reverse proxy vers http://127.0.0.1:5423

nicolas84 · Le 13/09/2019, à 13:25

@bruno

Il n'est pas possible de mettre ce serveur sur serveur_distant c'est pour de la vidéosurveillance et je veux que ce soit avant tout en local.

Je vois à peut près ce qu'est un reverse proxy mais j'aimerais ensuite faire le même système pour d'autres protocole que http.. RDP par exemple. Et la je pourrais pas utiliser reverse proxy je pense ? C'est pour ça que je cherche plus un système de redirection de port... Si ça existe...

Merci encore pour ton aide !

Dernière modification par nicolas84 (Le 13/09/2019, à 13:28)

Zakhar · Le 13/09/2019, à 16:48

Il faut commencer par morceaux.

Là tu nous montres donc la communication entre ton "serveur public" et le "serveur de surveillance" (appelons les ainsi).
Le tcpdump a l'air de montrer qu'il y a du flux qui passe.

Est-ce le cas, quand tu fais une requête en étant connecté au serveur public en ssh par exemple (si une telle chose est possible).

Et une fois que ce morceau fonctionne, il faut ensuite tester le "bout en bout".

Si tu commences d'emblée pour le "bout en bout", il peut y avoir tellement de choses qui plantent (mauvais paramétrage ou autre) que c'est inextricable, d'autant que comme le fait remarquer Bruno, tu t'es lancé dans un truc qui est un vrai défi tellement c'est une construction alambiquée !

cqfd93 · Le 13/09/2019, à 18:09

Modération

Bonjour,

Pour ajouter toi-même les balises code à ton message #5 :

Cliquer sur le lien « Modifier » en bas à droite du message
Sélectionner le texte
Cliquer sur le <> de l'éditeur de message

nicolas84 · Le 14/09/2019, à 05:03

@Zakhar

Oui tout a fait. Comme je l'ai dit dans mon premier message, c'est vraiment le dernier morceau que je n'arrive pas a debloquer... La connexion fonctionne lorsque je suis connecté en ssh a serveur_distant. Je fait le test avec cette commande :

wget http://127.0.0.1:5423

Cela me télécharge bien le index.html de la page de vidéosurveillance.
Merci encore pour ton aide

Dernière modification par nicolas84 (Le 14/09/2019, à 05:04)

nicolas84 · Le 14/09/2019, à 07:57

Ca y est j'ai trouvé comment faire.

J'ai tout simplement installé simpleproxy et l'ai lancé avec la commande suivante :

simpleproxy -L 5424 -R 127.0.0.1:5423  #Ajouter -d pour lancer en arrière plan

Mon application est maintenant accessible sur http://ip_serveur_distant:5424

Je viens de tenter avec RDP ça fonctionne aussi

Merci à vous deux !

Dernière modification par nicolas84 (Le 15/09/2019, à 08:42)

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1 Le 13/09/2019, à 11:03

[Résolu] Redirection de port

#2 Le 13/09/2019, à 12:17

Re : [Résolu] Redirection de port

#3 Le 13/09/2019, à 12:31

Re : [Résolu] Redirection de port

#4 Le 13/09/2019, à 13:06

Re : [Résolu] Redirection de port

#5 Le 13/09/2019, à 13:22

Re : [Résolu] Redirection de port

#6 Le 13/09/2019, à 13:24

Re : [Résolu] Redirection de port

#7 Le 13/09/2019, à 13:25

Re : [Résolu] Redirection de port

#8 Le 13/09/2019, à 16:48

Re : [Résolu] Redirection de port

#9 Le 13/09/2019, à 18:09

Re : [Résolu] Redirection de port

#10 Le 14/09/2019, à 05:03

Re : [Résolu] Redirection de port

#11 Le 14/09/2019, à 07:57

Re : [Résolu] Redirection de port

Pied de page des forums