Bonjour,
Étant comme beaucoup de gens confronté à un blocage de port, je voudrais élaborer une solution dont voici le principe :
Donnée du problème :
* Serveur x en local qui est en écoute d'une connections sur un port y
* Serveur HTTP (apache qui héberge mon sites ainsi que d'autres services)
* Un client z qui ne peux pas se connecter directement au serveur x car le port y est bloqué en sortie par le routeur.
Le mode de communication entre le client z et le serveur x est asynchrone donc le client envoie des données (requêtes) au serveur et vice-versa.
Principe :
Voilà : le souci c'est comment faire passer une session TCP via le port 80 pour finalement être relayer sur le port y...
Ce que je voudrais c'est par exemple :
z commence une session TCP avec apache sur le port 80
z envoie une requête une requête "GET /dossier-redirect/" (On suppose que apache est configuré de telle manière que l'accès au dossier /dossier-redirect/ fait appel à un module ou script CGI nommé s).
s récupère le no de socket (descripteur de fichier) associé à la connexion http avec z
s commence une session TCP avec le serveur x sur le port y
en fin s relaye les données de s vers z et vice-versa jusqu'à ce que z ou s effectue une clôture de session tcp.
voilà, je sais que c'est assez tordu mais ma question c'est : est ce que c'est faisable ? et est ce qu'il y aurait d'autre alternatives.
ps: ce que je voudrais éviter, c'est un proxy http ou tunnel http...
merci d'avance
# SSH
Posté par Obsidian . Évalué à 2.
Maintenant, si tu veux faire un point d'entrée depuis l'extérieur, tu peux effectivement faire un CGI avec un execv() et hériter du socket (enfin, il me semble), mais ça nécessite d'avoir un client adapté à cela. En plus, ça ne sert à rien car : soit tu as un filtrage au niveau du port uniquement et dans ce cas, le tunnel SSH fonctionne très bien, soit tu as un firewall un peu plus sioux et il te bloquera tout ce qui ne ressemble pas au contenu d'une requête HTTP convenable.
Bon courage.
[^] # Re: SSH
Posté par Benjamin (site web personnel) . Évalué à 2.
Exemple : le routeur peut vérifier que sur le 21, tu ne fais que des commandes FTP, que tu fais bien du HTTP sur le port 80 etc.
Or, il y a une faille bien souvent dans ce type d'appli : le 443, souvent relayé tel quel, ou, au mieux, le routeur à pare-feu applicatif vérifie juste qu'il s'agit bien de dialogue SSL. Or, SSH et HTTPS ont ce point commun ;)
Moralité, installer un serveur ssh sur le port 443 peut parfois s'avérer très utile, ...
Après, une fois ssh ouvert, -L et -R (voire -D, furieux va ! ) sont vos amis
[^] # Re: SSH
Posté par Toto . Évalué à 1.
Ex :
www.domaine.com:443 --> site web legitime
ssh.domaine.com:443 --> le serveur ssh
Petit howto ici : http://dag.wieers.com/howto/ssh-http-tunneling/
[^] # Re: SSH
Posté par Emeric . Évalué à 1.
le truc c'est que le client doit être le plus transparent possible pour l'utilisateur landa sans passer par du tenneling et utilisable derrière un firewall d'un boite ou d'une FAC, etc...
En plus, j'ai aussi un serveur https qui utilise le port 443
Le bon côté c'est que mon protocole de com entre x et z est déjà en ssl donc je pense passer par un script CGI via le port 443 et donc le firewall ne verra que du feu :-)
# [résolu] module apache
Posté par Emeric . Évalué à 1.
Pour ceux que ça intéresserait, voici l'adresse du code : http://svn.mr-ti.com/mod_ucfwd/trunk/mod_ucfwd.c
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.