On 23/06/22 at 03:04 +0200, David Ponzone wrote:
> > Le 22 juin 2022 à 21:31, Lucas <lucas.nussb...@loria.fr> a écrit :
> >
> > Bonjour David,
> >
> > On 22/06/22 at 20:53 +0200, David Ponzone wrote:
> >> Petite question aux utilisateurs d’une offre MVNO(-light) Bouygues:
> >>
> >> Vous avez remarqué qu’il y avait des restrictions IP sur le traffic data ?
> >
> > Ton mail me fait remarquer qu'un mail que j'avais essayé d'envoyer il y
> > a quelques jours, concernant un MVNO Bouygues, n'est pas passé. Je viens
> > de le renvoyer.
> >
> > Tu constates ça avec quel MVNO ? Attention, je crois que certains MVNO
> > Bouygues (ceux de ex-EuroInformation Telecom) conservent un coeur de
> > réseau spécifique (c'est mon cas avec NRJ Mobile).
>
> EIT est un full-MVNO. A ce titre, on peut imaginer qu’ils ont fait un choix
> différent pour le CGNAT.
> A priori, tous les MVNO(-light) de Bouygues devraient avoir le problème
> puisqu’ils se reposent totalement sur l’infra Bouygues.
>
> >> Du genre les communications TCP sur certains ports qui passent mais sont
> >> altérées par le CGNAT.
> >
> > Que constates-tu exactement comme altération ?
>
> L’outil Speedtest de Mikrotik permet de tester la bande passante up/down
> entre 2 Mikrotiks.
> Et bien ça échoue.
> Le début de la connexion se fait normalement.
> Si A est le Mikrotik derrière le CGNAT, ça donne:
> A (TCP RANDOM) — — —SYN—— — —> B (TCP 2000)
> A ((TCP RANDOM) <———SYN ACK——— B (TCP 2000)
> A (TCP RANDOM) — — — ACK —— — —> B (TCP 2000)
>
> Ensuite B envoie un TCP PSH à A.
> Avec le CGNAT Bouygues, A ne reçoit jamais ce PSH.
>
> Ce qui est rigolo, c’est que si à la place du CGNAT Bouygues, j’ai un FTTO
> propre mais qui traverse ensuite un Fortinet , j’ai le MÊME comportement.
> Et justement, il est connu que FortiOS reconnait l’échange du protocole
> Speedtest de MK sur le port TCP 2000 comme du SCCP, et fout le boxon à cause
> d’un ALG à la con (j’ai à ce jour pas réussi à le désactiver, j’ai pas
> cherché très très fort ceci dit, mais c’est plus compliqué que pour couper le
> SIP ALG).
>
> De là à penser que le CGNAT Bouygues, c’est du Fortinet, il n’y a qu’un pas.
> Vu en plus que Bouygues et Fortinet ont communiqué il y a quelques années sur
> un partenariat sur du Fortigate-VM...
>
> Sur le fond, je vais pas faire un cake pour un port TCP mais comme je peux
> pas savoir s’il y en a pas (plein) d’autres, ça va être bye-bye Bouygues.
Intéressant. Je reproduis le problème avec mon abonnement NRJ Mobile
(EIT), par exemple avec:
server$ nc -l -p 2000 > t
client$ dd if=/dev/urandom bs=5k count=1 > t
client$ nc -N server 2000 < t
Ce qui est amusant, c'est que le client recoit bien des ACK en échange
des données, mais ce n'est pas le serveur qui les envoie. D'ailleurs le
TTL des ACK est de 62, contre un TTL de 51 pour les ACK d'un échange
normal (sur un autre port).
La fin de connexion n'est pas filtrée, mais est réécrite pour que les
données qui ont été interceptées mais acquittées par la middlebox ne
perturbent pas l'échange.
Vu du client, ça donne:
53160 → 2000 [FIN, ACK] Seq=5121 Ack=1 Win=64256 Len=0 TSval=3941021092
TSecr=1817006976
2000 → 53160 [FIN, ACK] Seq=1 Ack=5122 Win=180224 Len=0 TSval=1817006982
TSecr=3941021091
53160 → 2000 [ACK] Seq=5122 Ack=2 Win=64256 Len=0 TSval=3941021152
TSecr=1817006982
mais vu du serveur, ça donne:
2612 → 2000 [FIN, ACK] Seq=1 Ack=1 Win=180224 Len=0 TSval=1817006982
TSecr=2630718538
2000 → 2612 [FIN, ACK] Seq=1 Ack=2 Win=65280 Len=0 TSval=2630718559
TSecr=1817006982
2612 → 2000 [ACK] Seq=2 Ack=2 Win=180224 Len=0 TSval=1817006984 TSecr=2630718559
=> le numéro de séquence ("relatif", c'est ce que wireshark affiche) est
5121 vu du client, mais 1 vu du serveur.
Le TTL élevé (62) fait penser que c'est l'un des premiers équipements
qui réalise cette opération, ce qui expliquerait pourquoi on voit le
problème à la fois avec Bouygues et EIT.
Lucas
---------------------------
Liste de diffusion du FRnOG
http://www.frnog.org/
