Explication serveur VPS
- Auteur du sujet Calixte
- Date de début
Je rentre pas trop dans les détails et je me trompe peut être mais si tu comprends pas certaines choses hésite pas.
Tu utilises un VPS loué chez OVH et qui tourne sous Debian 12 (une version de linux).
Ensuite pour ton serveur web, tu as un dossier avec ton app.py, et une base de données auquel ton application python doit être reliée.
Pour transformer ton app.py en page web, tu utilises Gunicorn et Uvicorn (je connais pas, je peux pas aider), et Gunicorn va diffuser ton site web sur le port 4000 (ou 4500, j'ai du mal à lire). Idéalement, ce port ne doit pas être accessible par un autre appareil.
Pour ne pas exposer au monde entier le serveur (si il y avait une faille, sur Uvicorn, ça pourrait permettre de faire des actions malicieuses sur ton VPS) :
Tu utilises donc Nginx (un reverse proxy) qui, si tu fais une requête sur le port 8080 (souvent utilisé pour les proxy), la redirigera vers le port de ton application Gunicorn.
Nginx se met donc entre l'utilisateur et ton application.
C'est donc à ce port (8080) que les appareils (à gauche) se connectent à ton serveur.
Tu peux te connecter en SSH (j'ai un doute vu le port), et les paramètres du SSH sont dans /etc/ssh/sshd_config.
Tu utilises un VPS loué chez OVH et qui tourne sous Debian 12 (une version de linux).
Ensuite pour ton serveur web, tu as un dossier avec ton app.py, et une base de données auquel ton application python doit être reliée.
Pour transformer ton app.py en page web, tu utilises Gunicorn et Uvicorn (je connais pas, je peux pas aider), et Gunicorn va diffuser ton site web sur le port 4000 (ou 4500, j'ai du mal à lire). Idéalement, ce port ne doit pas être accessible par un autre appareil.
Pour ne pas exposer au monde entier le serveur (si il y avait une faille, sur Uvicorn, ça pourrait permettre de faire des actions malicieuses sur ton VPS) :
Tu utilises donc Nginx (un reverse proxy) qui, si tu fais une requête sur le port 8080 (souvent utilisé pour les proxy), la redirigera vers le port de ton application Gunicorn.
Nginx se met donc entre l'utilisateur et ton application.
C'est donc à ce port (8080) que les appareils (à gauche) se connectent à ton serveur.
Tu peux te connecter en SSH (j'ai un doute vu le port), et les paramètres du SSH sont dans /etc/ssh/sshd_config.
Dernière édition:
Je complémente la réponse d'Edgar avec de la théorie (ceux qui sont plus forts que moi, n'hésitez pas à me corriger si je dis des choses incorrectes)
NGINX, le reverse proxy, va faire ce qu'on appelle dans le jargon un forward de port (une redirection de port). C'est un peu comme un agent SNCF à la gare, qui peut venir te voir pour te demander où tu veux aller et ensuite t'indiquer le bon train. On peut aussi faire du forward de port avec un firewall (sur linux c'est avec iptables ou ufw), même s'il y a des différences, NGINX c'est plus au niveau application (avec une redirection des requêtes HTTP/HTTPS), et iptables/ufw c'est au niveau réseau (donc plus bas niveau, ce qui permet de contrôler plus de trucs et d'autres protocoles)
Et si Edgar dit qu'il a un doute au niveau du port de SSH, c'est parce que par défaut (et généralement c'est mieux de laisser par défaut), SSH utilise le port 22. Maintenant, j'imagine que ton prof s'est pas trompé, la réponse qui me semble la plus logique c'est que c'est pour utiliser SSH dans du HTTP (du tunneling SSH over HTTP), dans le cas où le pare-feu bloque tout sauf le HTTP, donc pour contourner on envoie le trafic du SSH dans le port du HTTP
(PS: Edgar, c'est où que tu vois 453 de marqué ? Je vois pas moi, j'ai l'impression que le SSH est sur le 80, donc sur le port HTTP)
NGINX, le reverse proxy, va faire ce qu'on appelle dans le jargon un forward de port (une redirection de port). C'est un peu comme un agent SNCF à la gare, qui peut venir te voir pour te demander où tu veux aller et ensuite t'indiquer le bon train. On peut aussi faire du forward de port avec un firewall (sur linux c'est avec iptables ou ufw), même s'il y a des différences, NGINX c'est plus au niveau application (avec une redirection des requêtes HTTP/HTTPS), et iptables/ufw c'est au niveau réseau (donc plus bas niveau, ce qui permet de contrôler plus de trucs et d'autres protocoles)
Et si Edgar dit qu'il a un doute au niveau du port de SSH, c'est parce que par défaut (et généralement c'est mieux de laisser par défaut), SSH utilise le port 22. Maintenant, j'imagine que ton prof s'est pas trompé, la réponse qui me semble la plus logique c'est que c'est pour utiliser SSH dans du HTTP (du tunneling SSH over HTTP), dans le cas où le pare-feu bloque tout sauf le HTTP, donc pour contourner on envoie le trafic du SSH dans le port du HTTP
(PS: Edgar, c'est où que tu vois 453 de marqué ? Je vois pas moi, j'ai l'impression que le SSH est sur le 80, donc sur le port HTTP)
453 ? Je vois un espèce de 4000 ou 4050 entre Nginx et Gunicorn mais je me trompe sûrement x)
Je crois que c'est un 8080 (assez classique il me semble)
Post scriptum: Pingouin m'a recadré, et c'est forcément du 4050 vu que c'est du reverse proxy, mea culpa
J'avais aucune idée que 4050 était associé aux reverse proxy, je suis pas un expert en ports (même si j'ai des services sur 15 ports différents)Je crois que c'est un 8080 (assez classique il me semble)
Post scriptum: Pingouin m'a recadré, et c'est forcément du 4050 vu que c'est du reverse proxy, mea culpa
Vous lisez quoi vous ?
A priori : 8010 ou 8030 ou 8080.
Ouais j'apporte rien, mais j'attends plus de détails de la part de Calixounet
Et donc ssh sur le port 80 ?? A la base c'est port 22, donc il part clairement de modifier ça et de prendre le port 80, ce qui est très surprenant car le port 80 c'est le port HTTP. Donc juste pour casser les couilles il veut une redirection ? A moins qu'il y ait une raison précise que je n'ai pas là...
Mon Dieu !! j'y comprends rien à vos chiffres et vos lettres TwT je voualis faire informatique mais...finalement je vais aller en lettre et langue 
8080
. un accès SSH via le port 2226
. la mise en place du HTTPS forcé
. l'accès à l'API via *lien* sur le port 80 ou 443 (standard)
. une architecture avec NGINX, GUnicorn, Uvicorn/FastAPI
. une base de données MariaDB
si ça peut t'aider
