Depuis mon VPN FDN (FDN est un Fournisseur d'Accès à Internet associatif), je veux renouveler mon abonnement à NextInpact, journal sur le numérique et le droit afférant. L'intermédiaire de paiement par carte bancaire est Payzen. Dans le cadre de 3-D Secure, Payzen affiche une pop-up qui, in fine, me redirige vers ma banque pour la saisie d'un code à usage unique.
Cette pop-up, dont l'URL est « https://natixispaymentsolutions-3ds-vdm.wlp-acs.com/acs-challenge-browser-service/challenge/challengeRequest/browserBase », ne s'affiche pas.
Je désactive une à une mes extensions Firefox (uBlock Origin, uMatrix, Privacy Badger, LocalCDN, SmartReferer, NoScript, etc.). Ça ne fonctionne pas mieux. J'utilise Chromium avec un profil vierge (pas d'extension, pas de configuration personnalisée) : même absence de résultat. Dans les deux cas, le « délai de la réponse » est « dépassé ».
Regardons ça.
$ host natixispaymentsolutions-3ds-vdm.wlp-acs.com
natixispaymentsolutions-3ds-vdm.wlp-acs.com is an alias for natixispaymentsolutions-3ds-vdm.as8677.net.
natixispaymentsolutions-3ds-vdm.as8677.net has address 160.92.41.82
$ telnet 160.92.41.82 443
Trying 160.92.41.82...
telnet: Unable to connect to remote host: Connection timed out
D'après Wireshark
, mon telnet
reçoit aucune réponse à son TCP SYN. Il ne s'agit donc pas d'un problème de MTU, mais de joignabilité du service.
Ce que confirme mtr
:
$ mtr -n -r -c1 -T -P 443 160.92.41.82
Start: 2021-02-20T14:54:48+0100
HOST: <CENSURE> Loss% Snt Last Avg Best Wrst StDev
1.|-- 80.67.179.1 0.0% 1 16.9 16.9 16.9 16.9 0.0
2.|-- 80.67.169.42 0.0% 1 16.5 16.5 16.5 16.5 0.0
3.|-- 80.67.168.210 0.0% 1 16.8 16.8 16.8 16.8 0.0
4.|-- 37.77.34.14 0.0% 1 18.3 18.3 18.3 18.3 0.0
5.|-- 193.253.13.205 0.0% 1 22.1 22.1 22.1 22.1 0.0
6.|-- 193.252.98.122 0.0% 1 18.6 18.6 18.6 18.6 0.0
7.|-- 193.252.230.34 0.0% 1 19.5 19.5 19.5 19.5 0.0
8.|-- 160.92.6.57 0.0% 1 28.5 28.5 28.5 28.5 0.0
9.|-- ??? 100.0 1 0.0 0.0 0.0 0.0 0.0
Mes paquets se perdent à l'entrée du réseau de Worldline France Hosting, qui héberge le site web.
Notons que j'ai bien effectué un test en TCP (« -T ») et sur un port forcément ouvert (« -P 443 » = HTTPS) afin de ne pas obtenir un faux positif lié au blocage très fréquent d'ICMP dans ce milieu-là (même si c'est une connerie car des pans d'ICMP sont inoffensifs et utiles pour dépanner, comprendre l'origine d'une panne, retourner une erreur, etc.).
$ telnet 160.92.41.82 443
Trying 160.92.41.82...
Connected to 160.92.41.82.
Escape character is '^]'.
Ha, tiens, ça fonctionne.
$ mtr -n -r -c1 -T -P 443 160.92.41.82
Start: 2021-02-20T14:59:16+0100
HOST: viki.guiguishow.info Loss% Snt Last Avg Best Wrst StDev
1.|-- 51.77.212.1 0.0% 1 0.3 0.3 0.3 0.3 0.0
2.|-- 192.168.143.254 0.0% 1 0.2 0.2 0.2 0.2 0.0
3.|-- 10.224.71.126 0.0% 1 0.4 0.4 0.4 0.4 0.0
4.|-- 10.224.68.50 0.0% 1 0.4 0.4 0.4 0.4 0.0
5.|-- 10.69.96.102 0.0% 1 0.4 0.4 0.4 0.4 0.0
6.|-- 10.17.193.104 0.0% 1 0.7 0.7 0.7 0.7 0.0
7.|-- 10.73.8.114 0.0% 1 0.3 0.3 0.3 0.3 0.0
8.|-- 10.95.48.8 0.0% 1 1.5 1.5 1.5 1.5 0.0
9.|-- 94.23.122.137 0.0% 1 3.9 3.9 3.9 3.9 0.0
10.|-- 10.200.0.0 0.0% 1 3.4 3.4 3.4 3.4 0.0
11.|-- ??? 100.0 1 0.0 0.0 0.0 0.0 0.0
12.|-- 62.115.124.118 0.0% 1 3.5 3.5 3.5 3.5 0.0
13.|-- 62.115.121.5 0.0% 1 26.3 26.3 26.3 26.3 0.0
14.|-- 62.115.153.109 0.0% 1 3.8 3.8 3.8 3.8 0.0
15.|-- 160.92.6.39 0.0% 1 3.8 3.8 3.8 3.8 0.0
16.|-- 160.92.6.54 0.0% 1 13.6 13.6 13.6 13.6 0.0
17.|-- 160.92.6.10 0.0% 1 16.6 16.6 16.6 16.6 0.0
18.|-- 160.92.41.82 0.0% 1 16.4 16.4 16.4 16.4 0.0
On remarque que le routage est différent.
OVH utilise l'un de ses transitaires, l'opérateur Telia.
Gitoyen (l'opérateur associatif duquel FDN est membre) passe par Hopus / Orange.
À ce stade, j'ai utilisé la fonctionnalité proxy SOCKS / transfert dynamique de ports de SSH (ssh -D
) tout en configurant mon Firefox pour l'utiliser, et, hop, j'ai pu renouveler mon abonnement NextInpact.
$ telnet 160.92.41.82 443
Trying 160.92.41.82...
Connected to 160.92.41.82.
Escape character is '^]'
Ça fonctionne également.
$ mtr -n -r -c1 -T -P 443 160.92.41.82
Start: 2021-02-20T15:09:14+0100
HOST: <CENURE> Loss% Snt Last Avg Best Wrst StDev
1.|-- 192.168.1.1 0.0% 1 0.5 0.5 0.5 0.5 0.0
2.|-- ??? 100.0 1 0.0 0.0 0.0 0.0 0.0
3.|-- 193.253.91.46 0.0% 1 3.2 3.2 3.2 3.2 0.0
4.|-- 193.252.160.150 0.0% 1 2.2 2.2 2.2 2.2 0.0
5.|-- 193.251.126.18 0.0% 1 7.7 7.7 7.7 7.7 0.0
6.|-- 193.252.99.102 0.0% 1 9.2 9.2 9.2 9.2 0.0
7.|-- 193.252.98.122 0.0% 1 8.7 8.7 8.7 8.7 0.0
8.|-- 193.252.230.34 0.0% 1 10.7 10.7 10.7 10.7 0.0
9.|-- 160.92.6.57 0.0% 1 11.6 11.6 11.6 11.6 0.0
10.|-- 160.92.6.10 0.0% 1 13.3 13.3 13.3 13.3 0.0
11.|-- 160.92.41.82 0.0% 1 15.0 15.0 15.0 15.0 0.0
On remarque que l'on transite aussi par les routeurs 160.92.6.57, 193.252.230.34, 193.252.98.122, comme depuis mon VPN FDN. Mais, ici, ça fonctionne. Curieux.
Ça ressemble quand même à un problème localisé, pas général. Dois-je signaler la panne à mon FAI (FDN) ? Est-ce de sa responsabilité ? Pas sûr du tout.
Je pourrais les solliciter sur les listes de diffusion… ou utiliser RIPE Atlas. Faisons ça.
Je crée deux mesures :
Paramètres communs aux deux mesures :
Probe selection :
Résultats des mesures :
TLS :
Si l'on fait une mesure TLS depuis la France entière (et pas uniquement depuis l'opérateur Gitoyen), on constate que 797 sondes sur 874 (91 %) parviennent à établir une session TLS, 75 n'y parviennent pas (« handshake failure ») et 2 sondes ne parviennent pas à joindre la cible (timeout). Voir la mesure numéro 29125405.
Afin de tester le chemin retour (qui est rarement identique au chemin aller), j'aurais bien effectué une mesure ping / traceroute depuis Worldline vers ma station de travail, mais aucune sonde Atlas est présente dans le réseau de Worldline.
Il ne s'agit pas d'une panne généralisée, car l'écrasante majorité des sondes Atlas et des machines que j'ai sous la main parviennent à joindre le site web.
Pire, les autres abonnés de mon FAI parviennent à joindre le site web, y compris un autre VPN qui est dans le même réseau que moi. Nous suivons le même itinéraire pour atteindre l'hébergeur du site web, donc, a priori, il n'y a pas de problème à ce niveau-là.
Comment expliquer ce problème lié à mon adresse IP ?
curl
et wget
ainsi que des dizaines de telnet
et de mtr
TCP et je n'ai pas été bloqué.
Au moment de publier ce shaarli (le 23/02, 6 jours après le premier constat), j'accède de nouveau à ce site web depuis mon VPN FDN :
$ mtr -n -r -c1 -T -P 443 160.92.41.82
Start: 2021-02-23T10:53:57+0100
HOST: <CENSURE> Loss% Snt Last Avg Best Wrst StDev
1.|-- 80.67.179.1 0.0% 1 22.1 22.1 22.1 22.1 0.0
2.|-- 80.67.169.42 0.0% 1 18.3 18.3 18.3 18.3 0.0
3.|-- 80.67.168.210 0.0% 1 16.8 16.8 16.8 16.8 0.0
4.|-- 37.77.34.14 0.0% 1 21.7 21.7 21.7 21.7 0.0
5.|-- 193.253.13.205 0.0% 1 16.7 16.7 16.7 16.7 0.0
6.|-- 193.252.98.122 0.0% 1 19.2 19.2 19.2 19.2 0.0
7.|-- 193.252.230.34 0.0% 1 19.9 19.9 19.9 19.9 0.0
8.|-- 160.92.6.57 0.0% 1 28.2 28.2 28.2 28.2 0.0
9.|-- ??? 100.0 1 0.0 0.0 0.0 0.0 0.0
10.|-- 160.92.41.82 0.0% 1 35.1 35.1 35.1 35.1 0.0
On constate que j'emprunte le même chemin, à l'intérieur des réseaux d'Orange et de Worldline, que la machine hébergée sur un abonnement fibre Orange, ce qui est cohérent. L'hypothèse d'un problème de routage (sur le chemin retour) s'effrite encore plus.
On constate également que je me trompe ci-dessus : mes paquets ne se perdaient pas à l'entrée du réseau de Worldline, mais au contraire, à ma destination dans ce réseau. Cela conforte l'hypothèse d'un banissement temporaire type fail2ban.
Bizarre… Je viens d'effectuer des centaines de requêtes GET et POST et je ne suis pas bloqué…
Au final, je ne saurai pas ce qui s'est passé… Les ninjas de l'informatique ne savent pas tout…