Certains hébergent bloquent le port 53 (AWS il me semble).

Finalement j'ai ma réponse, en testant sur https://ipv4.bouygues.testdebit.info:53/1G.iso

Le serveur Online
wget https://ipv4.bouygues.testdebit.info:53/1G.iso -O /dev/null
--2022-11-06 15:53:56--  https://ipv4.bouygues.testdebit.info:53/1G.iso
Resolving ipv4.bouygues.testdebit.info (ipv4.bouygues.testdebit.info)... 89.84.1.186
Connecting to ipv4.bouygues.testdebit.info (ipv4.bouygues.testdebit.info)|89.84.1.186|:53... connected.
HTTP request sent, awaiting response... 200 OK
Length: 1000000000 (954M) [application/x-iso9660-image]
Saving to: ‘/dev/null’

/dev/null                   100%[=========================================>] 953.67M  95.9MB/s    in 10s     

2022-11-06 15:54:07 (93.4 MB/s) - ‘/dev/null’ saved [1000000000/1000000000]

La connexion FTTH ByTel, toujours aux alentours de 40Mbps

wget https://ipv4.bouygues.testdebit.info:53/1G.iso -O /dev/null
--2022-11-06 15:54:29--  https://ipv4.bouygues.testdebit.info:53/1G.iso
Résolution de ipv4.bouygues.testdebit.info (ipv4.bouygues.testdebit.info)… 89.84.1.186
Connexion à ipv4.bouygues.testdebit.info (ipv4.bouygues.testdebit.info)|89.84.1.186|:53… connecté.
requête HTTP transmise, en attente de la réponse… 200 OK
Taille : 1000000000 (954M) [application/x-iso9660-image]
Sauvegarde en : « /dev/null »

/dev/null                    32%[============>                             ] 310,60M  3,54MB/s    tps 2m 48s


Orange 4G

wget https://ipv4.bouygues.testdebit.info:53/1G.iso -O /dev/null           130 ↵
--2022-11-06 15:56:26--  https://ipv4.bouygues.testdebit.info:53/1G.iso
Résolution de ipv4.bouygues.testdebit.info (ipv4.bouygues.testdebit.info)… 89.84.1.186
Connexion à ipv4.bouygues.testdebit.info (ipv4.bouygues.testdebit.info)|89.84.1.186|:53… connecté.
requête HTTP transmise, en attente de la réponse… 200 OK
Taille : 1000000000 (954M) [application/x-iso9660-image]
Sauvegarde en : « /dev/null »

/dev/null                    15%[=====>                                    ] 144,11M  10,6MB/s    tps 94s
Donc pas de blocage du tcp/53 sur Orange 4G au moins.

Merci du signalement.

C'est intéressant.

Je reformule : Il y a donc une analyse du contenu des paquets UDP sur le port 53.

Protocole sur les couches supérieur :
- DNS : Les paquets passent bien (client => serveur => client)
- OpenVPN : Les paquets sont rejetés

Tu as essayé en diminuant la MTU ?

Non, les paquets étant ridiculement petits (<70 octets) ça ne m'a pas effleuré l'esprit.

Côté serveur.
1: 44321 > 53 size: 60 proto: OpenVPN MessageType: P_CONTROL_HARD_RESET_CLIENT_V2
2: 53 > 44321 size: 68 proto: OpenVPN MessageType: P_CONTROL_HARD_RESET_SERVER_V2
3: 53 > 44321 size: 56 proto: OpenVPN MessageType: P_CONTROL_HARD_RESET_SERVER_V2
4: 44321 > 53 size: 60 proto: OpenVPN MessageType: P_CONTROL_HARD_RESET_CLIENT_V2
5: 53 > 44321 size: 64 proto: OpenVPN MessageType: P_ACK_V1
6: 53 > 44321 size: 56 proto: OpenVPN MessageType: P_CONTROL_HARD_RESET_SERVER_V2
7: 44321 > 53 size: 60 proto: OpenVPN MessageType: P_CONTROL_HARD_RESET_CLIENT_V2
8: 53 > 44321 size: 64 proto: OpenVPN MessageType: P_ACK_V1
9: 44321 > 53 size: 60 proto: OpenVPN MessageType: P_CONTROL_HARD_RESET_CLIENT_V2
10: 53 > 44321 size: 68 proto: OpenVPN MessageType: P_CONTROL_HARD_RESET_SERVER_V2

Côté client.
1: 44321 > 53 size: 56 proto: OpenVPN MessageType: P_CONTROL_HARD_RESET_CLIENT_V2
2: 44321 > 53 size: 56 proto: OpenVPN MessageType: P_CONTROL_HARD_RESET_CLIENT_V2
3: 44321 > 53 size: 56 proto: OpenVPN MessageType: P_CONTROL_HARD_RESET_CLIENT_V2
4: 44321 > 53 size: 56 proto: OpenVPN MessageType: P_CONTROL_HARD_RESET_CLIENT_V2
5: 44321 > 53 size: 56 proto: OpenVPN MessageType: P_CONTROL_HARD_RESET_CLIENT_V2


Bonjour,

le respect de la neutralité du Net ne se situe pas qu'à un aspect technique comme le blocage de ports...
Elle est mise à mal par toute forme d'altération du trafic comme de la priorisation (ex: limiter les torrents ou Youtube) ou de l'altération des flux (ex.: modification des réponses DNS, entêtes HTTP, blocage de ports), un mauvais routage aussi peut compter Et cela peux-être pour plein de des raisons différentes (politiques, juridiques, idéologiques...).
Le projet Ooni (https://ooni.org/ ) essaye de mesurer par pays la neutralité sur certains indicateurs comme l'accès à certains sites (ça pique en particulier pour l'Iran et la Chine).
Vous pouvez aussi aller voir des trucs comme https://www.aquilenet.fr/services/test-de-neutralit%C3%A9/ qui peuvent donner des idées sur des tests de ports ouverts.

Les navigateurs web ont restreint la liste des ports utilisables, donc https://www.aquilenet.fr/services/test-de-neutralit%C3%A9/  n'est pas fiable : c'est généralement le navigateur qui bloque l'ouverture des ports (pour des raisons de sécurité).

c'est indiqué dans la page et comment désactiver ce blocage dans le navigateur Firefox
D'autre part l'outil peut être aussi intéressant pour tester cela en ligne de commande
Après c'est un outil expérimental hein

En cli, j'utilise parfois comme ça :

Code: [Sélectionner]

$ sudo nmap -4 -sS -p25 neutral-echo.aquilenet.fr | grep -E "PORT|smtp"
PORT   STATE    SERVICE
25/tcp filtered smtp
$ sudo nmap -6 -sS -p25 neutral-echo.aquilenet.fr | grep -E "PORT|smtp"
PORT   STATE SERVICE
25/tcp open  smtp
$


oui c'est une utilisation, tu peux faire aussi
$ nc neutral-echo.aquilenet.fr 25
kikoooooo
kikoooooo
neutral-echo.aquilenet.fr répond le même message que tu lui envoie si cela fonctionne (d'où le deuxième kikoooooo). A la place de netcat on peut aussi utiliser un bon vieux telnet

oui c'est une utilisation, tu peux faire aussi

Code: [Sélectionner]

$ nc neutral-echo.aquilenet.fr 25
kikoooooo
kikoooooo
neutral-echo.aquilenet.fr répond le même message que tu lui envoie si cela fonctionne (d'où le deuxième kikoooooo). A la place de netcat on peut aussi utiliser un bon vieux telnet

C'est top ce serveur neutral-echo.aquilenet.fr !

Cela permet de tester pleins de ports rapidement en ligne de commande.

Je retiens la chose pour des prochains tests.

Merci Sacha