Recherchez dans la Communauté

Vous avez une question ?

Interrogez la communauté

internet & fixe ma connexion

Problème ouverture de port NAT/PAT Livebox play

JujuLand
contributeur confirmé
contributeur confirmé
7 439  

Re: Re : Problème ouverture de port NAT/PAT Livebox play

Réponse à jojo:

 

Vrai à travers le net (pour de l'IPv4), mais c'est normal. Quand on se connecte à un ordi à travers le net, on donne l'adresse de la box, et c'est le port qui fait la différence entre les machines. Donc, même si on peut râler sur le livebox (et il y a quelques raisons), dans le cas d'espèce, la livebox n'a rien à voir avec ce problème qui n'en n'est pas un.

 

Faux sur un LAN, ou les adresses sont données par la livebox (192.168.1.xx) et donc différentes entre chaque machine.

 

Vrai probablement pour l'IPv6, là, car la livebox semble être trop restrictive, vu que dans les règles, elle associe un port à une machine, si mes souvenirs sont exacts.

 

[Edit]

Bon, j'avais mal lu le post, et il est vrai que je n'avais jamais essayé d'utiliser un port différent entre entrant et sortant. Toutes mes machines ont le même port en entrant et en sortant de la box. Bien sûr, ports différents entre machines si je désire me connecter à travers le net.

 

A+

 

jojoledémago
contributeur occasionnel
7 422  

Re: Re : Problème ouverture de port NAT/PAT Livebox play

"Bien sûr, ports différents entre machines si je désire me connecter à travers le net."

Ports différents depuis le net oui mais pas forcément sur les machines auxquelles je veux accéder depuis le net si je pouvais configurer un "forward" correctement...

PhilDur
#TopMembre
#TopMembre
7 412  

Re: Re : Problème ouverture de port NAT/PAT Livebox play


@jojoledémago  a écrit :
1ère règle NAT : PortEntrant=22 PortSortant=22 appareil=PC1

2ème règle NAT : PortEntrant=1022 PortSortant=22 appareil=PC2

...

Et bien impossible sur Livebox ! En tous cas pour moi, impossible d'utiliser le même port, même pour 2 PC distincts... Obligé de modifier le port SSH de chaque serveur et créer ceci :

1ère règle NAT : PortEntrant=22 PortSortant=22 appareil=PC1
2ème règle NAT : PortEntrant=1022 PortSortant=1022 appareil=PC2

...

Là ça fonctionne ! Mais quel bord.... !


Je ne comprends pas, ça devrait fonctionner : PC1:22 et PC2:22 ne sont pas en conflit.

C'est très exactement ce que tu as avec deux imprimantes sur le même LAN tes deux serveurs d'impressions sont bien à l'écoute sur le même port.

 

Es-tu certains d'avoir configuré correctement tes deux machines PC1 et PC1

Aucune machine ne doit avoir d'adresse IP configurée en dur.

Les machines PC1 et PC2 doivent toutes les deux être configurées en adressage automatique.

Le DHCP de la Livebox doit être utilisé.

Chaque machine PC1 et PC2 doit faire l'objet d'un bail DHCP fixe dans la Livebox.

 

 

C'est vrai que la configuration du DHCP des Livebox est un vrai bord d'aile.

Dans une règle NAT, l'adresse utilisée est celle de la machine cible au mement de la création de la règle, si  ils avaient utilisé le nom de la machine avec une résolution du nom en dynamique on ne serait même pas obligé de passer par un bail fixe. Cela dit c'est probablement mieux au niveau performance, mais ça reste à prouver.

 

Cordialement

PhilDur

Faites confiance aux produits libres : Firefox, Thunderbird, LibreOffice, Irfanview, VLC, 7-zip, FileZilla
Votre machine vous en remerciera
verdy_p
contributeur confirmé
contributeur confirmé
7 403  

Re: Re : Problème ouverture de port NAT/PAT Livebox play

La Livebox semble plutôt bien marcher avec DHCP, tant que les logiciels correspondant sont compatibles avec le protocole UPNP qui peut remplacer la plupart des règles NAT+PAT statiques.

De nombreuses applications savent utiliser UPNP aujourd'hui. Mais pour un usage plus permanent (exemple : hébergemetn de site web à domicile), la solution reste encore d'assigner un numéro de port statique réservé à une seule machine du réseau local et faire du NAT simple (sans translation de port), ou de configurer une machine du réseau locale comme DMZ (destination par défaut du trafic non réservé dynamiquement à une machine), à elle ensuite de faire le routage si nécessaire.

 

Nombre d'applis "serveur" qu'on installe sur une machine locale ont une API type web, et HTTP(S) est assez universel pour surpporter divers sous-protocoles: il ne lui siffit en effet que d'un seul port pour tout faire. Cependant c'est pas forcément idéal pour faire autre chose que livrer des contenus statiques, ou faire des requêtes dirigées via une API de sous-protocole web (de type REST API, DAV, ou proxy HTTP) ou du streaming HTTP pour les flux audio/vidéo.

 

En effet HTTP étant basé sur TCP, il nécessite d'établir d'abord une session bidirectionnelle, et la connexion au port serveur unique alloué va demander d'allouer un second port pour communiquer avec le client distant, et le nombre de ports disponible est limité : la session ne pourra pas être permanente sous peine de tomber à court de ports disponibles pour répondre aux demandes de conenxion des clients, et chaque allocation va demander l'allocation d'un tampon mémoire de communication important (les deux "fenêtres TCP" pour la réception et la transmission); de plus comme TCP est conçu comme un protocole "fiable", ne permet pas facilement d'ignorer des paquets manquants, et il s'en suit des délais qui peuvent ralentir le traitement du reste du flix qui reste en attente même s'il est déjà bien transmis.

 

Si on veut plus d'interactivité et éviter ces pauses, on passe plutôt par UDP pour avoir une granularité plus fine permettant d'ignorer les paquets non reçus ou arrivent trop tard et de de resynchroniser vite sur le reste et de supprimer la couteuse barrière mémoire des fenêtres TCP. Dans ce cas HTTP ne fonctionnne pas de la façon attendue et va produire des erreurs de coupure sessions en cas de perte de trames ou rupture de session trop longue.

 

Si on est en UDP, il est difficile de l'utiliser comme unique point d'entrée d'un service, même avec UPNP. En général un compromis est fait en utilisant les deux protocoles: un protocole de contrôle à bas débit pouvant utiliser des sessions temporaires (mais faibles) en TCP, basé sur HTTP avec des requêtes courtes et simples (et compatibles UPNP et avec les proxies), un autre protocole secondaire pour transmettre les flux interactifs sur lesquels on accepte un niveau de dégradation de qualité globale, au profit d'une meilleure interactivité.

 

Les deux parties (clients et serveur) se mettent d'accord via le canal TCP (HTTP) sur les numéros de ports à utiliser en UDP. Puis communiquent directement. UPNP est utilisé lors de l'établissement de l'accord par l'applicaton serveur pour demander la réservation ou désallouer la suppression d'une route NAT et on n'a pas besoin alors de translation de port.

 

Le PAT (translation de port) est un pis-aller. Une box Internet grand public n'est pas prévue pour faire ça, et il vaut mieux se tourner vers des applications compatibles avec UPNP qui est plus universel et plus ouvert. Le PAT reste maintenant utilisé massivement par les fournisseurs d'accès (notamment en IPv4 depuis qu'il est saturé et que ceux-ci doivent payer maintenant plus cher les tranches d'adresses IPv4 dont ils ont besoin pour leurs abonnés) par des règles automatiques (par exemple pour partager la même adresse IPv4 entre 4 abonnés, en allouant à chacun une tranche de 16384 ports TCP ou UDP et non la tranche complète des ports 0 à 65535, comme le fait Free maintenant par défaut).

 

Le PAT n'est pas utile du tout en IPv6 puisque'au lieu de de scinder les ports, IPv6 permet de router non pas une seule adresse vers un client mais tout un bloc très large au moins 32 bits, 48 bits recommandés, parfois 64 bits chez certains fournisseurs d'accès) : un client peut configuer une interface réseau pour écouter toute une série d'adresses IPv6 sans avoir à faire aucune translation de ports ni modifier le routage sur le réseau local, ni utiliser aucun système UPNP, et il peut encore plus facilement isoler les services locaux de ceux destinés à communiquer avec Internet. Et le fournisseur d'accès n'a plus non plus à s'occuper de ces détails: ils achemine tout trafic destiné à n'importe quelle adresse située dans le gros bloc d'adresses IPv6 alloué à son client final. Et localement IPv6 permet une configuration totalement automatique (zeroconfig) pour les applications et machines qui choisissent elles-mêmes de se connecter uniquement au réseau local (les adresse IPv6 dans le bloc alloué) ou à l'Internet (toute tranche d'adresses IPv6 hors du bloc alloué et de quelques blocs "spéciaux" réservés à la compatibilité IPv4 ou aux communications sur un segment local).

 

Il ne reste que NAT qui servira localement comme interface locale de routage entre IPv6 avec Internet et IPv4 sur le réseau local, et dont le fournisseur d'accès ne s'occupera pas.

 

Vive IPv6, adieu NAT et PAT ! C'est bien plus simple que vous imaginez. Et contrairement à une ancienen légende persistante, IPv6 est même maintenant plsu rapide qu'IPv4 car il est routé bien plus efficacement et gère nttement mieux les priorités de trafic et bien plus économes en protocoles annexes pour régler divers problèmes hérités dans IPv4. Certes les trames IPv6 sont légèrement plus grandes, mais il en faut moins, il y a besoin de moins de protocoles annexes, des tas d'options qui doivent polluer les trames IPv4 sont externalisées au lieu de s'intégrer dans les trames, IPv6 est donc nettement plus fiable (il est également bien plus stable en terme de routabilité et de reconfigation des plans de routage inter-réseaux, et permet une bien meilleur isolation et segmentation, donc une sécurisation plus facile à améliorer; globalement aussi les routes suivies ont beaucoup moisn de "hop" et les délais de réponse sont améliorés, et les routeurs économisent plein de mémoire pour les fenêtres TCP qui n'ont pas besoin d'être aussi grandes pour que TCP reste fiable, d'autant plus qu'on n'est plus limtié en nombre de ports et qu'on faire beaucoup plus de sessions TCP/HTTP en parallèle entre deux mêmes hôtes, et donc gérer plus facilement les priorités de trafic pour la même application, au lieu de fire du multiplexage sur un unique port TCP/HTTP)

 

Vous avez une question ?

Interrogez la communauté

Déjà 753056 membres inscrits 🧡

3000 personnes actuellement en ligne

Tous les membres en ligne