GuiGui's Show

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.

Depuis ma station de travail

$ 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.).

S'agit-il d'un problème général ou localisé ?

Depuis le serveur qui héberge ce shaarli

$ 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.

Depuis un abonnement fibre Orange

$ 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.

D'autres abonnés de mon FAI ont-ils le même problème ?

Je pourrais les solliciter sur les listes de diffusion… ou utiliser RIPE Atlas. Faisons ça.

Je crée deux mesures :

• SSL (qui porte très mal son nom : SSL a été remplacé par TLS depuis fort longtemps) :
  • Target : 160.92.41.82
    
    
  • Hostname (SNI) : natixispaymentsolutions-3ds-vdm.wlp-acs.com
• Traceroute :
  • Target : 160.92.41.82
    
    
  • Protocol : TCP
    
    
  • Port : 443

Paramètres communs aux deux mesures :

• Probe selection :

  • ASN = AS20766 (il s'agit du numéro d'opérateur de Gitoyen)
• One-off

Résultats des mesures :

• TLS :

  • 3 sondes sur 4 parviennent à établir une session TLS. Celle qui n'y parvient pas en affichant « handshake failure » est probablement trop ancienne pour savoir établir une session TLS 1.2 (seul protocole supporté par la cible). Merci Stéphane ;
    
    
  • On remarquera la présence d'une sonde située derrière un VPN FDN. Cette sonde parvient à établir une session TLS ! Son traceroute est identique au mien !
• Traceroute :
  • Toutes les sondes passent par le même chemin mais se font bloquer avant d'entrer sur le réseau de Worldline. D'après la documentation, « !A » dans le traceroute d'une sonde Atlas signifie que l'erreur ICMP « administratively prohibited » a été renvoyée à la sonde. Merci Stéphane.

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.

Conclusion

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 ?

• Certaines adresses IP (X.X.X.0 ou X.X.X.255) sont désavantagées car considérées comme invalides selon des normes qui ne sont plus en vigueur depuis plusieurs décennies. Mon adresse IP ne fait pas partie des lots problématiques connus ;
  
  
• Limitation de trafic ou bannissement temporaire (type fail2ban) dûs à mes essais infructueux en désactivant mes extensions Firefox. Cela me semble être improbable car :
  • Mes premiers essais datent de mercredi 17/02 (et déjà RIPE Atlas voyait aucun problème général) et je rencontrais encore ce problème le 20/02, ce qui est inhabituellement long pour ce type de blocage et dans ce contexte (on préfère prendre plus de risques mais encaisser le pognon que de faire perdre des ventes) ;
    
    
  • Depuis mon serveur OVH, j'ai effectué des rafales de plusieurs centaines de requêtes HTTP, GET et POST, avec 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…