Auteur Sujet: Bridage du port udp 53 ?  (Lu 6268 fois)

0 Membres et 1 Invité sur ce sujet

nicox11

  • Abonné Orange Fibre
  • *
  • Messages: 190
  • Toulouse (31)
Bridage du port udp 53 ?
« Réponse #12 le: 01 mai 2023 à 15:53:50 »
On va travailler sur un nouvel outil pour tester la neutralité qui permettra de tester tous les ports. Plutôt sous forme de script pour Linux, Windows et Mac. Peut-être qu'il faudrait prévoir une app mobile, mais on n'a pas les compétences.

Là, il serait intéressant de savoir si le problème est lié au fixe ou au mobile.

Si tu prends un port autre que le port 53 et le port 80, cela fonctionne ?

Pas de problème sur le port udp 80.
J'ai pu faire le test en partage de connexion, et ça confirme bien ce que j'ai observé.

J'ai le client avec l'IP en f0ba et le serveur en 4693.

Sur la capture du routeur on voit les paquets reçu et envoyé vers mon peer : une requête du client obtient toujours au moins une réponse et parfois une retransmission du SYN ACK (cf pj).

Par contre sur le tcpdump du PC en partage de connexion, on voit uniquement les paquets envoyé :

13:30:37.756003 IP6 ****:****:****:****:****:****:****:f0ba.42474 > ****:****:****:****:****:****:****:4693.53: 1024 [33649a] [40207q] [256n] Type0 (Class 214)? . [|domain]
13:30:38.756136 IP6 ****:****:****:****:****:****:****:f0ba.42474 > ****:****:****:****:****:****:****:4693.53: 1024 [33649a] [40207q] [512n] Type0 (Class 65)? . Type54214 (Class 50092)? <BAD PTR> [|domain]
13:30:40.772257 IP6 ****:****:****:****:****:****:****:f0ba.42474 > ****:****:****:****:****:****:****:4693.53: 1024 [33649a] [40207q] [768n] Type0 (Class 223)? . [|domain]
13:30:44.804231 IP6 ****:****:****:****:****:****:****:f0ba.42474 > ****:****:****:****:****:****:****:4693.53: 1024 [33649a] [40207q] [1024n] Type0 (Class 202)? . Type38578 (Class 6368)? M-^DM-^O7M-2HM/^R3-KM-!M-upM-E]M-iM-cWvM-VlM-;M-CM-_HM-bM-I$M-H5XM-^FM-djM-,M-IM-<5M-~M-6]M-*M-WM-^MzM-JM-^TM-]hM-fyaM-^PM-ez^N.^Vh^K3M-^\^\M-;M-aM-J^XM-kM-IuJM-^^M-`M-a,M-$5SM-R^(.<BAD PTR> [|domain]
^C
7 packets captured
7 packets received by filter
0 packets dropped by kernel

Ça semble indiquer que les paquets udp 53 entrant sur le réseau mobile sont bloqué.

Je n'ai pas encore eu la possibilité d'effectuer le test avec un client ailleurs que sur un réseau 4G pour vérifier ça. Je suppose que de client Orange fixe vers Orange fixe il doit pas y avoir de problème.

Les ports 80/81520 udp ne posent aucun problème.

simon

  • Abonné Orange Fibre
  • *
  • Messages: 935
Bridage du port udp 53 ?
« Réponse #13 le: 01 mai 2023 à 16:30:59 »
Taking a wild guess.

Vu qu'on a un firewall à état (connection tracking) pour empêcher le traffic non sollicité dans le sens internet -> mobile, il faut garder en mémoire la liste des flux établis par chaque mobile quelque part (en RAM sur l'équipement qui fait le connection tracking, normalement). On ajoute ùne entrée dans la liste lors de l'établissement de la connexion et on la retire lorsque la connexion est fermée.

Autant en TCP il est facile de savoir quand une connexion est fermée (on attend de voir passer un échange FIN/FIN-ACK), autant en UDP, on a pas de marqueur de fin de connexion (UDP n'a pas de notion de connexion, d'ailleurs).
On utilise donc un timer qui est réarmé à chaque paquet UDP traversant le firewall. Lorsque le timer expire, le flux est considéré comme fermé et on retire l'entrée de la liste.

DNS est un protocole qui utilise UDP pour la majorité de ses requêtes, avec un port source aléatoire par requête côté client, et le port 53 côté serveur. Comme on peut facilement avoir une centaine de requête DNS par page Web (ca peut aller très vite... regardez le nombre de domaines contactés par www.lemonde.fr ou www.lequipe.fr sur un navigateur sans adblocker... avec une requête AAAA, une A et une HTTPS par domaine, je pense même qu'on est au dela de 100), on va avoir autant de flux de très courte durée vus par le firewall.

Je pense donc que pour éviter de faire exploser les tables de connection tracking, Orange traite les paquets UDP port 53 de façon un peu différente, par exemple avec un timer très court. Tant qu'il y a du traffic sur le VPN, pas de souci. Dès qu'il y a une période d'inactivité plus longue que le timer, le flux UDP utilisé par le VPN est marqué comme terminé et l'entrée correspondante est retirée de la liste : les paquets dans le sens internet -> mobile sont jetés par le firewall et tu constates une interruption de service.

Lorsque le mobile émet à nouveau des paquets pour ce flux, une nouvelle entrée est créée par le firewall (qui pense que c'est une nouvelle connexion) et le VPN apparaît à nouveau fonctionnel.

Ce n'est qu'une théorie, mais ca me semble plus être une réponse pragmatique qu'une atteinte à la neutralité :
- l'opérateur n'a pas le droit de regarder le contenu applicatif du paquet pour déterminer si c'est une requête DNS ou autre chose, il ne peut donc pas appliquer ce traitement spécifique uniquement aux requêtes DNS,
- les firewalls limitent probablement le nombre de flux ouverts par client pour éviter une saturation des tables de conntrack et une dégradation de service pour tous les clients,
- au vu de la fragilité relative des liens 2/3/4/5G actuels (ressource radio précieuse car spectre cher, autonomie batterie limitée, niveau de cybersécurité faible des mobiles, etc.), il est judicieux de faire du connection tracking dans le réseau mobile pour protéger les mobiles des attaques extérieures.

Je suppose que tu fais écouter ton serveur Wireguard sur 53/udp pour contourner des portails captifs. Ne pourrais-tu pas le faire écouter sur les deux ports (53 et 51820) et n'utiliser le port 53 que si tu es sur un tel réseau ?

nicox11

  • Abonné Orange Fibre
  • *
  • Messages: 190
  • Toulouse (31)
Bridage du port udp 53 ?
« Réponse #14 le: 01 mai 2023 à 17:13:11 »
Je ne suis pas trop d'accord avec toi.

Citer
Je pense donc que pour éviter de faire exploser les tables de connection tracking, Orange traite les paquets UDP port 53 de façon un peu différente, par exemple avec un timer très court. Tant qu'il y a du traffic sur le VPN, pas de souci. Dès qu'il y a une période d'inactivité plus longue que le timer, le flux UDP utilisé par le VPN est marqué comme terminé et l'entrée correspondante est retirée de la liste : les paquets dans le sens internet -> mobile sont jetés par le firewall et tu constates une interruption de service.

Le problème est le flux retour, pour chaque flux retour bloqué, il y a eu un flux aller quelques millisecondes plus tôt. Dans ce cas là, le timer en question aurait du être rafraichi et autoriser le flux retour. Par exemple, j'ai trouvé beaucoup de blocage après de simple SYN (et donc les SYN ACK bloqués).

Citer
- l'opérateur n'a pas le droit de regarder le contenu applicatif du paquet pour déterminer si c'est une requête DNS ou autre chose, il ne peut donc pas appliquer ce traitement spécifique uniquement aux requêtes DNS,

Je suis pas trop d'accord non plus. Pour mon vpn, le flux est bloqué en retour.
Par contre si je fais une boucle bash assez violente de ce style :
while true; do dig google.fr +trace; done;
En gros requêter à fond du DNS, jamais je n'ai de flux UDP retour bloqué sur un même port udp 53 (je vois pas Orange risquer ça d'ailleur, bloquer du DNS classique). Pour moi il y a forcement une inspection ou quelque chose de ce style que détecte que mes paquets ne sont pas du DNS pur et flag ça comme du malveillant.

Citer
- au vu de la fragilité relative des liens 2/3/4/5G actuels (ressource radio précieuse car spectre cher, autonomie batterie limitée, niveau de cybersécurité faible des mobiles, etc.), il est judicieux de faire du connection tracking dans le réseau mobile pour protéger les mobiles des attaques extérieures.

Connection tracking, je ne sais pas, mais des systèmes anti-ddos c'est fort probable.

Citer
Je suppose que tu fais écouter ton serveur Wireguard sur 53/udp pour contourner des portails captifs. Ne pourrais-tu pas le faire écouter sur les deux ports (53 et 51820) et n'utiliser le port 53 que si tu es sur un tel réseau ?

Oui c'est certainement ce que je vais faire, même si j'aurais eu envie d'éviter de faire du NAT (par exemple rediriger le port 51820 vers le 53 en interne). Surtout qu'on est sur de l'IPv6. Maintenant l'idée du post c'est plutôt de voir pourquoi il y a ce blocage/filtrage, si c'est vraiment acceptable ou non aux yeux du concept de neutralité que de débloquer ma situation (qui ne l'est pas vraiment, il y a des contournements).

simon

  • Abonné Orange Fibre
  • *
  • Messages: 935
Bridage du port udp 53 ?
« Réponse #15 le: 01 mai 2023 à 18:03:35 »
On peut pas passer plusieurs options ListenPort à Wireguard pour éviter d'avoir à faire du DNAT ?

> while true; do dig google.fr +trace; done;
Si tu fais ca, dig devrait utiliser un port source différent à chaque invocation. Ce n'est pas le cas ? Sur mon laptop ceci dit, il tape dans systemd-resolved qui fait office de cache, donc ca ne génère pas des masses de traffic réseau, mais c'est un détail d'implémentation.

Pour le reste, tu as sans doute raison, j'ai probablement tort. C'était juste une tentative d'explication rationnelle.

> Maintenant l'idée du post c'est plutôt de voir pourquoi il y a ce blocage/filtrage, si c'est vraiment acceptable ou non aux yeux du concept de neutralité
La réponse m'intéresse en tout cas :) D'ailleurs, j'irai plus loin : si un opérateur a des filtres anti-IP spoofing (voeux pieux, mais j'espère qu'ils en ont tous!), est-ce une atteinte au concept de neutralité ?

Plus on-topic et de facon plus large, l'unidirectionnalité des connexions induite par la présence de ce connection tracking / stateful filtering bloque clairement des applications et restreint les usages. Même si c'est fait dans l'intérêt du grand public, le fait qu'on ne puisse pas le désactiver est-il acceptable également ?

vivien

  • Administrateur
  • *
  • Messages: 47 276
    • Twitter LaFibre.info
Bridage du port udp 53 ?
« Réponse #16 le: 01 mai 2023 à 18:04:43 »
Le problème est présent en IPv4 également (si possible avec le mobile configuré en APN IPv4 only) ?

Je souhaiterais savoir si c'est une régression IPv6)

nicox11

  • Abonné Orange Fibre
  • *
  • Messages: 190
  • Toulouse (31)
Bridage du port udp 53 ?
« Réponse #17 le: 02 mai 2023 à 19:07:21 »
Le problème est présent en IPv4 également (si possible avec le mobile configuré en APN IPv4 only) ?

Je souhaiterais savoir si c'est une régression IPv6)

J'ai restesté aujourd'hui, et le comportement est similaire avec un tunnel en IPv4.

nicox11

  • Abonné Orange Fibre
  • *
  • Messages: 190
  • Toulouse (31)
Bridage du port udp 53 ?
« Réponse #18 le: 20 mai 2023 à 11:08:28 »
A priori pas de blocage d'internet Fibre vers Fibre. Donc surement un protection sur le réseau mobile uniquement.

matrix-bx

  • Fédération FDN
  • *
  • Messages: 85
Bridage du port udp 53 ?
« Réponse #19 le: 21 mai 2023 à 17:40:34 »
Bonjour Vivien,

Le problème est présent en IPv4 également (si possible avec le mobile configuré en APN IPv4 only) ?

Je souhaiterais savoir si c'est une régression IPv6)

C'est assez proche du souci que j'ai signalé ici en Octobre dernier.

Je n'avais pas re testé depuis un moment, surprise mon vpn s'établit maintenant bien en udp 53 (ipv4) en 4G.
Il faudrait donc que je test plus avant pour voir si j'observe des déconnexions.

Bon Dimanche.