Auteur Sujet: IPv6 chez Bouygues... (Lu 133731 fois)

kgersen · « **Réponse #240 le:** 31 mars 2017 à 21:01:56 »

tu cherches je ne sais quoi la ...

NAT 1:N = NAPT avec un seule ip "extérieure" (d'ou le "1") -> voir https://tools.ietf.org/html/rfc2663#section-4.1.2 pour NAPT.

corrector · « **Réponse #241 le:** 31 mars 2017 à 21:18:22 »

Et donc, est-ce qu'un peut inventer un protocole arbitraire sur un port arbitraire sur une seule connexion TCP vers l'extérieur?

Même le port 21?

kgersen · « **Réponse #242 le:** 31 mars 2017 à 21:29:10 »

Citation de: corrector le 31 mars 2017 à 21:18:22

Et donc, est-ce qu'un peut inventer un protocole arbitraire sur un port arbitraire sur une seule connexion TCP vers l'extérieur?

Même le port 21?

what ?!
La notion de port est lié au protocole lui meme, IP n'a pas cette notion.

Donc de base, NATP ca ne marche qu'avec UDP et TCP. Apres au fil du temps et des usages, certains routeurs et OS implèmentent le support (souvent partiel) d'autre protocoles comme GRE ou ICMP par exemple.

Mais dans tout les cas, il faut bien que le code qui fait le NAPT connaisse les protocoles qui passent pour pouvoir les tracker et les NATer. Donc si quelqu'un invente un nouveau protocole ca ne marchera pas ou alors, par défaut, que pour une seule adresse interne, la première qui initie un flux avec ce protocole (dans ce cas ca fait juste du NAT 1-1 sans translation de port).

corrector · « **Réponse #243 le:** 31 mars 2017 à 21:42:34 »

Pourtant la question est simple!

Est-ce qu'une application sur une seule connexion TCP qui utilise le port TCP 8888 peut décider d'utiliser le port 21 à la place, oui ou non?

corrector · « **Réponse #244 le:** 31 mars 2017 à 22:10:49 »

Autrement dit :

Pour tout numéro de port valide x,
Si je reconfigure un serveur Apache chez un hébergeur pour le mettre sur un port TCP x, et que je pointe mon navigateur (chez moi, derrière la machinbox) sur ce port, tu es d'accord que je dois pouvoir accéder à ce serveur?

Si je fais de même avec un serveur qui écoute juste sur un port, comme Apache, mais qui implèmente un autre protocole (qui n'est pas HTTP, donc), ça doit aussi marcher, non?

Le serveur ne peut pas être un serveur FTP parce que par hypothèse il n'y a qu'une seule connexion, toujours vers le même port.

kgersen · « **Réponse #245 le:** 01 avril 2017 à 09:06:38 »

tu melanges un peu les niveaux (couches réseau) et la notion de protocole la...

NAPT concerne la protocole de transport (couche 4: tcp,udp,etc) et que le protocole de transport (c'est vrai qu'on emploi le meme terme 'protocole' sans toujours préciser la couche concerné, c'est en général déductible du contexte).

HTTP, FTP c'est au dessus, ce sont des protocoles d'applications (couche 7).

donc si un flux TCP 'passe' la box, le protocole d'application qui l'utilise au dessus passe lui aussi (sauf cas très particuliers qui en général ne respectent pas les couches réseau).

donc oui tu peux héberger un serveur web sur le port 20: http://portquiz.net:20/ (ce serveur écoute en http sur tous les 65535 ports possibles sauf quelques uns utilisés pour autre chose) et y accéder en étant derrière un NAPT.

corrector · « **Réponse #246 le:** 01 avril 2017 à 14:21:22 »

Citation de: kgersen le 01 avril 2017 à 09:06:38

donc oui tu peux héberger un serveur web sur le port 20: http://portquiz.net:20/ (ce serveur écoute en http sur tous les 65535 ports possibles sauf quelques uns utilisés pour autre chose) et y accéder en étant derrière un NAPT.

Amusant : Google Chrome refuse d'aller sur cette page :

ERR_UNSAFE_PORT

kgersen · « **Réponse #247 le:** 01 avril 2017 à 15:35:49 »

Citation de: corrector le 01 avril 2017 à 14:21:22

Amusant : Google Chrome refuse d'aller sur cette page :

ERR_UNSAFE_PORT

oui Chrome bloque certains ports s'ils ont utilisés pour faire du HTTP:

https://src.chromium.org/viewvc/chrome/trunk/src/net/base/net_util.cc?view=markup#l68

la raison: pour pas que Chrome servent de relais d'attaque (via js) sur des services utilisant ces protocoles. C'est une bonne démarche et dommage que tous les navigateurs ne la suivent pas.

pour ceux qui ont besoin quand même d'utiliser un ou plusieurs de ces ports, il y a une option de lancement qui le permet: --explicitly-allowed-ports port1, port2, etc

par exemple: lancer chrome avec l'option "--explicitly-allowed-ports = 20"

corrector · « **Réponse #248 le:** 01 avril 2017 à 15:58:33 »

Beurk!!! À vomir!

C'est complètement ad hoc.

Et d'où sort la liste de ports interdits? C'est arbitraire. Beurk!

Nh3xus · « **Réponse #249 le:** 01 avril 2017 à 15:59:25 »

Firefox x64 52.0.2 bloque aussi ces choses là.

corrector · « **Réponse #250 le:** 01 avril 2017 à 16:15:31 »

Est-ce qu'il existe un standard?

kgersen · « **Réponse #251 le:** 01 avril 2017 à 16:18:13 »

Citation de: corrector le 01 avril 2017 à 15:58:33

Beurk!!! À vomir!

C'est complètement ad hoc.

Et d'où sort la liste de ports interdits? C'est arbitraire. Beurk!

Ca sort de la 'vie réelle' et des retours qu'ils ont eu. Ces services supportent peu ou mal qu'on leur envoi des requêtes http donc ca n'est pas une mauvaise idée en soi. Il y a une bonne explication avec un cas concret ici (qui date un peu): https://jazzy.id.au/2012/08/23/why_does_chrome_consider_some_ports_unsafe.html

C'est certain que c'est arbitraire et que ça ne protège pas tous les services et que dans l'absolu ce n'est probablement pas a Chrome de protéger ces services. Mais en pratique c'est efficace bien plus qu'on ne s'en rend compte.