On avance :)
Je confirme le TTL altéré par un équipement à 2 hops du terminal.
Je t’ai gardé le meilleur pour la fin: le port 5060 est concerné aussi.
Encore un point commun avec Fortinet qui par défaut fait de la merde sur SIP
(ça se désactive mais c’est pas trivial).
Le port MGCP n’est pas concerné par contre.
> Le 23 juin 2022 à 09:22, Lucas <lucas.nussb...@loria.fr> a écrit :
>
> 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/
