Forum général.général [Résolu] Questions protocoles Internet (IP & RTSP)

Posté par hugotrip le 08 avril 2025 à 10:57. Licence CC By‑SA.

Étiquettes :

avr.

2025

Bonjour à toutes et tous,

Devant cette année enseigner les SNT, j'ai eu l'opportunité d'approfondir pas mal de connaissances sur les différents thèmes du programme.

Néanmoins je suis tombé sur un os auquel je n'ai pas trouvé de réponse satisfaisante concernant l'adressage IP:

De nos jours il semble que récupérer l'adresse IP (via nslookup par exemple) d'un site web ne suffit souvent plus du tout a y accéder en la tapant dans la barre d'adresse du navigateur web. La plupart du temps j'atterrirai sur une page de base "serveur web" fraîchement installé ou cloudflare, …

Par exemple, j'ai cherché des sites néo-zélandais pour faire un joli traceroute, mais pour ceux qui n'étaient pas sur un data-center aux USA, je n'ai pas trouvé d'IP me permettant de joindre directement un site (heureusement les sites du gouvernement népalais fonctionnent encore à l'ancienne).

J'ai bien compris que cela venait du fait de "l'industrialisation des sites web" (via virtualisation, utilisation d'outils d'optimisation type cloudflare, …), mais donc je n'ai pas trouvé comment le navigateur web arrivait à accéder au site web.

Autrement dit : quelles autres informations doit-on transmettre à l'IP correspondante, voire où trouver ces informations ?

PS : sinon, pour décomposer une URL, j'ai cherché des adresses liées à d'autres protocoles mais n'ai rien trouvé avec rtsp : y a-t-il encore des serveurs librement accessibles de nos jours ou est-ce que c'est mort ?

# simple

Posté par NeoX le 08 avril 2025 à 11:43. Évalué à 6 (+3/-0).

1°) un nom de site linuxfr.org
2°) ton ordi fait une requete DNS pour connaitre l'IP du serveur qui fournit le site
3°) ton ordi se connecte à ce serveur, et demande à constuler le domaine "linuxfr.org"
4°) le serveur le renvoi vers le dossier qui va bien et qui contient linuxfr.org

apres tu peux mettre des intermediaires
ex à l'issu de 2°) tu obtiens l'IP d'un CDN (cloudflare)
3°) se connecte au CDN, demande le domaine "linuxfr.org"
4°) le CDN se connecte au serveur officiel, et lui demande le domaine "linuxfr.org"
5°) le serveur officiel affiche le contenu du dossier

maintenant une question, pour enseigner, il est bon de connaitre son sujet, voire d'avoir pratiqué.

peut-etre qu'il te faudrait monter un site toi meme, pour pouvoir tester les scenarios que tu vas presenter aux eleves.

un site web c'est le proto HTTP, aller lire la documentation (RFC) sur le sujet
pour RTSP bah aller lire la doc du RTSP
idem pour les autres protocoles FTP, SSH, SMTP, etc

Répondre
# Quelques pistes ...

Posté par totof2000 le 08 avril 2025 à 12:11. Évalué à 3 (+1/-0). Dernière modification le 08 avril 2025 à 12:11.

De nos jours il semble que récupérer l'adresse IP (via nslookup par exemple) d'un site web ne suffit souvent plus du tout a y accéder en la tapant dans la barre d'adresse du navigateur web.

La formulation n'est pas claire : j'ai du m'y reprendre à trois fois pour tenter de comprendre ce qui est dit …

J'ai bien compris que cela venait du fait de "l'industrialisation des sites web" (via virtualisation, utilisation d'outils d'optimisation type cloudflare, …), mais donc je n'ai pas trouvé comment le navigateur web arrivait à accéder au site web.

reverse proxy, virtualhost Apache par exemple (ou nginx : voir https://www.digitalocean.com/community/tutorials/how-to-set-up-nginx-server-blocks-virtual-hosts-on-ubuntu-16-04 ) pourront t'aider à comprendre pourquoi l'IP ne suffit plus ( le serveur web ou le reverse proxy analysent le FQDN de l'URI que tu demandes et te redirigent vers le bon site en fonction de cette information).

Tu peux le tester chez toi, sur ton PC avec des VMs et un dns local par exemple. En regardnt les logs des divers maillons de la chaine tu pourras comprendre le pourquoi du comment

Répondre
- [^] # Re: Quelques pistes ...
  
  Posté par hugotrip le 08 avril 2025 à 14:02. Évalué à 1 (+0/-0).
  
  Désolé si j'ai manqué de clarté.
  
  Sinon, pour les tests chez moi, je n'ai clairement pas le niveau pour monter un réseau virtuel de VMs et analyser ses communications. :(
  
  Répondre
  - [^] # Re: Quelques pistes ...
    
    Posté par NeoX le 08 avril 2025 à 15:00. Évalué à 4 (+1/-0).
    
    Sinon, pour les tests chez moi, je n'ai clairement pas le niveau pour monter un réseau virtuel de VMs et analyser ses communications. :(
    
    alors comment vas-tu l'expliquer à tes eleves ?
    
    Répondre
    - [^] # Re: Quelques pistes ...
      
      Posté par hugotrip le 09 avril 2025 à 14:29. Évalué à 5 (+4/-0).
      Réponse courte : je ne le fais pas :).
      Réponse longue : En fait il faut bien voir que le programme de SNT, s'adresse à tous les élèves de seconde et vise à aborder 7 chapitres sur une durée globale de 32 semaines × 1,5h = 48h, soit environ 7h par chapitre.
      
      Pour le chapitre internet, le contenu n'est donc pas très poussé :
      
      Protocole TCP/IP : paquets, routage des paquets
      
      Distinguer le rôle des protocoles IP et TCP. Caractériser les principes du routage et ses limites.
      
      Distinguer la fiabilité de transmission et l'absence de garantie temporelle.
      
      Adresses symboliques et serveurs DNS
      
      Sur des exemples réels, retrouver une adresse IP à partir d'une adresse symbolique et inversement.
      
      Réseaux pair-à-pair
      
      Décrire l'intérêt des réseaux pair-à-pair ainsi que les usages illicites qu'on peut en faire.
      
      Indépendance d'internet par rapport au réseau physique
      
      Caractériser quelques types de réseaux physiques : obsolètes ou actuels, rapides ou lents, filaires ou non.
      
      Caractériser l'ordre de grandeur du trafic de données sur internet et son évolution.
      
      En conséquence sur la partie TCP/IP, je me suis surtout contenté de faire un réseau en jeu de rôle : 3 (voire 4) élèves correspondait à un sous-réseau : un routeur, une machine client et une machine serveur, et chaque sous-réseau était en îlot, dispersés dans la salle.
      
      chaque client devait demander une image à un serveur distant, et la reconstituer à la fin.
      
      chaque serveur devait servir l'image demandée parmi celles dispos sur leur feuille, en la découpant en paquets (c'était des genres de space invaders NB sur une grille 8×8 à coder et découper en octet : 0 pour blanc, 1 pour noir)
      
      chaque routeur avait une table de routage pour faire suivre les paquets.
      
      Les paquets/messages étaient des petits bouts de papier préformatés à choisir et à compléter par les clients et serveurs.
      
      Ça a très bien marché, et si j'ai le temps cet été, je verrai pour éventuellement complexifier la simulation : rupture de liaison entre 2 routeurs, pour mettre à jour les tables de routage. La difficulté étant que je tiens à ce que globalement la charge des routeurs soit assez bien répartie pour que tous participent bien.
      
      Pour conclure, mon entrée de forum n'était pas fondamentale à l'enseignement, mais le questionnement sous-jacent était "Comment montrer aux élèves que l'adresse IP récupérée après interrogation des serveurs DNS correspond bien au site web demandé ?" : ça me semblait un peu de la triche de n'utiliser que les rares sites pour lesquels l'adresse IP entrée dans la barre d'adresse du navigateur suffit. La réponse plus bas de jeanas m'a permis de mieux comprendre pourquoi ce comportement était marginal, et en quoi l'adresse IP ne suffit pas, par définition.
      Répondre
      - [^] # Re: Quelques pistes ...
        
        Posté par NeoX le 09 avril 2025 à 16:52. Évalué à 4 (+1/-0).
        
        j'aime bien le coté pedagogique des tables en sous groupes de 3/4 personnes, avec un qui fait le "routeur"
        
        et les autres clients/serveurs, etc
        
        je peux m'en inspirer pour d'autres structures qui font ce meme genre de formation/sensibilisation (fablab par exemple) ?
        
        Répondre
        
        [^] # Re: Quelques pistes ...
        
        Posté par hugotrip le 09 avril 2025 à 22:45. Évalué à 2 (+1/-0). Dernière modification le 09 avril 2025 à 22:45.
        
        Pas de souci, de toute façon tu pourrais trouver sur le web plein de variantes de ces simulations de réseaux, plus ou moins poussées sur un aspect ou l'autre.
        
        Personnellement, ma base a été cet article, qui ne fournissait aucune ressource associée (au contraire d'autres), donc au cas où voici un tar.xv de ce que j'ai monté. Ce sont surtout des pdf pour que tu le voise tel que je l'ai fait, mais ils sont pleinement modifiables sous LibreOffice, et je t'encourage à les modifier : en particulier le réseau trop simple (pour être facile à mettre en place dans la salle) que j'ai construit à 7 îlots n'est pas optimisé : le routeur A ne fait que de l'émission/réception, et aucune transmission. Y a moyen de faire mieux. Mais l'intérêt est surtout de te donner des bases/modèles des documents à fournir aux participants.
        
        PS : En ce qui me concerne, je ne revendique aucune propriété intellectuelle sur ce que je mets à ta disposition.
        
        Répondre
  - [^] # Re: Quelques pistes ...
    
    Posté par totof2000 le 08 avril 2025 à 19:12. Évalué à 3 (+1/-0).
    
    Avec un bon tutoriel c'est beaucoup plus simple que tu ne le crois. Tu pourrais le faire avec une machine qui a quelques Go de RAM (pour y mettre un Virtualbox ou un libvirt/kvm). Il suffit juste d'être méthodique et on y arrive.
    
    Répondre
    - [^] # Re: Quelques pistes ...
      
      Posté par MicP le 09 avril 2025 à 12:39. Évalué à 3 (+2/-0).
      
      Bonjour
      
      Un outil que j'ai trouvé sympa pour simuler et apprendre le fonctionnement d'un réseau,
      c'est Packet Tracer.
      
      Cisco propose un cours (gratuit) qui pourrait t'intéresser : Notions de base sur les réseaux
      
      Répondre
      - [^] # Re: Quelques pistes ...
        
        Posté par hugotrip le 09 avril 2025 à 13:06. Évalué à 3 (+2/-0).
        
        Effectivement une solution de simulation intégrée de réseaux telle que Packet Tracer est plus facile à mettre en œuvre.
        Une réserve que j'ai sur cet outil est qu'il nécessite de s'inscrire sur le site correspondant de Cisco.
        De mes recherches sur internet, il semble que les collègues de SNT utilisent plutôt Filius (site en allemand) qui a en plus l'avantage d'être libre.
        
        Répondre
# En-tête Host et SNI

Posté par jeanas (site web personnel, Mastodon) le 08 avril 2025 à 12:19. Évalué à 10 (+8/-0). Dernière modification le 08 avril 2025 à 12:23.
Bonjour,

Prenons un exemple avec des requêtes à LinuxFR.
```
$ host linuxfr.org
linuxfr.org has address 213.36.253.103
linuxfr.org mail is handled by 50 main.linuxfr.org.
```
Le serveur de linuxfr.org est joignable à l'adresse IP 213.36.253.103. Pourtant, comme vous l'avez constaté sur d'autres sites, si on essaie de joindre https://213.36.253.103 sans précaution, on n'obtient pas la page d'accueil de LinuxFR. On peut reproduire dans un terminal avec curl ce que fait un navigateur :
```
$ curl --insecure https://213.36.253.103
<!DOCTYPE html>

<html lang="fr">
<head>
<meta charset="utf-8">
<title>Serveur oups.linuxfr.org - LinuxFr.org</title>
</head>

<body><h1>Serveur oups.linuxfr.org - LinuxFr.org</h1>
<p>Si vous êtes arrivé(e) sur cette page, c'est probablement parce que vous kiffez l'HTML 2.</p>
</body>

</html>
```
La raison à ceci est qu'un même serveur peut, sur une même IP, servir plusieurs sites Web différents. Quand il reçoit une connexion HTTP, il a besoin de savoir à quel site elle se rapporte. Or notre requête ne lui fournit pas cette information. Dans le protocole HTTP, elle est donnée dans l'en-tête Host, qu'on peut demander à curl d'envoyer comme ceci :
```
$ curl --insecure -H "Host: linuxfr.org" https://213.36.253.103
<!DOCTYPE html>
<html lang="fr">
<head>
<meta charset="utf-8">
<title>Accueil - LinuxFr.org</title>
[…]
```
Maintenant, il faut que j'explique pourquoi on a eu besoin de --insecure. Dans le bon vieux temps, les requêtes étaient faites en HTTP simple, et le Host suffisait. Mais est arrivé le HTTPS, qui rajoute une couche de chiffrement TLS par dessus le HTTP. Or, dans le début de la connexion TLS, avant même que des données soient transmises, le client est censé vérifier que le serveur a fourni un certificat, qui atteste qu'il est bien le serveur qu'il prétend être. Donc, si un serveur propose plusieurs sites, quand il reçoit une requête, il ne pouvait pas encore savoir quel site voulait le client, et devait forcément fournir un certificat valide pour tous les sites possibles. Le hic, c'est qu'il peut être compliqué, et un peu moins sécurisé aussi, d'obtenir un tel certificat. Pour pallier ce manque est arrivée la SNI, « Server Name Indication », une extension du protocole TLS qui permet au client de spécifier quel site il veut dès le début de la connexion TLS. Avec la commande ci-dessus, curl passe le Host mais pas la SNI, donc se plaint légitimement qu'il n'a pas de certificat valide pour 213.36.253.103 car le certificat envoyé par le serveur de LinuxFR n'est valide que pour linuxfr.org (et j'ai mis le --insecure pour lui demander de l'ignorer).

curl n'a apparemment pas d'option pour régler manuellement le SNI, donc je ne peux pas terminer l'exemple aussi pédagogiquement que je le voudrais, mais dans la requête curl https://linuxfr.org, il utilise l'URL non seulement pour trouver l'IP 213.36.253.103 via DNS, mais aussi pour régler le SNI dans la connexion TLS et le Host dans la connexion HTTP qu'elle chiffre.

Sur Wikipédia : https://en.wikipedia.org/wiki/List_of_HTTP_header_fields#Standard_request_fields et https://en.wikipedia.org/wiki/Server_Name_Indication

HTH
Répondre
- [^] # Re: En-tête Host et SNI
  
  Posté par hugotrip le 08 avril 2025 à 14:09. Évalué à 5 (+4/-0).
  
  Merci pour la piste de l'entête host dans le protocole HTTP : c'est effectivement ce qui me manquait.
  
  Je pense que ma confusion venait surtout de la confusion entre machine et serveur (qui n'est qu'un programme) : j'imagine que pour les sites où l'adresse IP entrée dans la barre d'adresses du navigateur suffit à accéder au site web, il n'y a sur la machine qu'un seul site web servi.
  
  Merci aussi pour les autres détails sur la communication moderne en HTTPS.
  
  Répondre
  - [^] # Re: En-tête Host et SNI
    
    Posté par NeoX le 08 avril 2025 à 15:04. Évalué à 6 (+3/-0).
    
    j'imagine que pour les sites où l'adresse IP entrée dans la barre d'adresses du navigateur suffit à accéder au site web, il n'y a sur la machine qu'un seul site web servi.
    
    toutafais, et c'est pour cela que parfois quand tu demande http://add.re.sse.ip tu tombes finalement sur une page "site non configuré" ou "it works, welcome to Apache/Nginx…"
    
    c'est souvent le site par défaut livré par le serveur
    
    Répondre

Envoyer un commentaire

Suivre le flux des commentaires

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