[Résolu] NAS SFR inaccessible depuis Livebox

[filoo]

Je n'arrive pas à joindre ta machine...
Je ne fais vraiment rien d'exceptionnel pour rendre accessible ma machine, c'est curieux quand même que ça ne fonctionne pas chez toi

[Inygo]

Merci filoo pour ton test.

Ce qui est exceptionnel (à mes yeux) c'est ce cas bizarre. La Terre entière accède à mon NAS sauf quelques livebox, dont tu fais maintenant partie (te voilà privilégié ;) ) 

 

Fenrir, j'ai testé :

- changement DNS => pareil

- rajouter une appli en écoute sur 80 => injoignable également (sauf ce fameux <title> qui se charge)

- changement du port (8080 était déjà pris j'ai fait 8888 vers 80) => pareil

- passage en https => pareil

- changement IP locale et redirection en conséquence => pareil

 

A noter que sans changement dans la conf, ça fonctionnait très bien depuis les livebox y'a un an par exemple (je sais pas si ça sert à quelque chose, mais ça me perturbe profondément !). 

Merci beaucoup Fenrir pour toutes ces pistes, mais j'suis à nouveau à poil 

 

 

[Fenrir]

Au contraire, ça permet d'éliminer pas mal de causes possibles.

Peux tu tester avec ces 4 autres ports :

• 15000
• 30000
• 45000
• 60000

[Inygo]

Me revoilà.

Alors j'ai testé de rediriger les ports 15000, 30000, 45000 et 60000 vers le port 80 du Syno.

J'en ai profité, 15001, 30001, 45001 et 60001 vers le port 443 du Syno.

 

J'ai un navigateur clean, j'ai suivi tes conseils. Pour les tests, j'ai désactivé le pare-feu et quelques détails, notamment HTTP/2.

Quand j'essaie de joindre http://IP_externe:15000 ça rame sans rien afficher, tout comme 30000, 45000 et 60000.

Quand j'essaie de joindre https://IP_externe:15000 ou (et pareil pour les autres port multiples de 15000), ça me dit "Echec de connexion sécurisée : SSL_ERROR_RX_RECORD_TOO_LONG". 

Quand j'essaie de joindre http://IP_externe:15001 (idem pour 30001 45001 et 60001) : j'ai une erreur nginx "400 bad request. The plein HTTP request was sent to HTTPS port". Pareil pour 60001.

Quand j'essaie de joindre https://IP_externe:15001 : ca mouline sans rien afficher (idem pour 30001 45001 et 60001.

 

Pour tous ces tests, j'ai pas l'option "rediriger automatiquement HTTP vers HTTPS" activée. 

Pour info, j'ai essayé de jouer avec le proxy inversé.

Sur ma box, j'ai redirigé le 15002 vers le 15002 du NAS.

Via le browser : La connexion a échoué.

Dans le proxy inversé, j'ai fait pointer le 15002 vers le 80. 

Via le browser en HTTP : Ca mouline, mais le titre se charge ("Bonjour, bienvenue dans Syno Web Station.")

 

A noter aussi, quand ça charge juste le titre, si j'affiche la source de la page, je vois les textes qui devraient normalement être affichés. Pour info 2, ça mouline trèèèès longtemps. Y'a pas de timeout.

[Inygo]

EDIT du soir.

Merci à Fenrir qui a passé une heure à chercher (et à trouver le problème). C'est pas une conf du NAS ni un soucis des box distantes, c'est sur le trajet que ça coince. Ca vient du fait que les paquets fragmentés passent pas comme il faut (bon, je m'embourbe, il l'expliquera 100 fois mieux que moi).

La solution de contournement, c'est de changer la MTU sur le PC distant (de la diminuer, en l’occurrence). C'est pas joli mais ça patche bien.

Encore merci Fenrir.

[Fenrir]

Il y a 1 heure, Inygo a dit :

Ca vient du fait que les paquets fragmentés passent pas comme il faut (bon, je m'embourbe, il l'expliquera 100 fois mieux que moi).

C'est bien ça, il y a un soucis dans l’ordonnancement dès qu'il faut fragmenter les paquets (ce qui explique pourquoi les ping, les petites pages, ... enfin tout ce qui n'a pas besoin d'être fragmenté, fonctionne correctement).

Un tracepath vers le syno en question ou d'autres adresses sfr indique qu'ils font du routage asymétrique, ce qui n'est pas nécessairement un problème - quand c'est correctement implémenté - mais peut générer le type de soucis rencontré ici.

Par contre ce n'est pas à un particulier de faire ce genre de chose (et encore moins de changer la mtu d'un poste). Pour moi c'est aux opérateurs de faire le diag et la correction qui s'impose et étant donné le comportement du traceroute depuis SFR, je les soupçonne aussi de bloquer l'ICMP et donc tous les mécanismes de détection de la MTU. Ça ressemble au comportement du réseau Numericable (il n'y aurait pas comme un lien ... ?).

il y a une heure, Inygo a dit :

La solution de contournement, c'est de changer la MTU sur le PC distant

Ou coté serveur, ça revient normalement au même, une manière moins sale de faire aurait été de créer une règle dans le firewall du nas pour abaisser la MTU juste pour les clients qui rencontrent le soucis (cible TCPMSS de la table mangle), mais mangle n'est pas présente sur les syno (par contre si tu avais eu un vrai routeur ça aurait été faisable).

À noter que baisser la MTU réduit les performances globale de TOUT le réseau (client-box-routeurs...-serveur), donc c'est à proscrire normalement.

nb : augmenter la MTU c'est pire => il ne faut pas jouer à ça non plus sans maitriser 100% des équipements impliqués (entre votre PC et votre nas, augmenter la mtu peut augmenter votre débit, mais dès que que vous passerez par un équipement avec une MTU plus faible, ça sera la cata).

Il y a 2 heures, Inygo a dit :

Encore merci Fenrir.

De rien, ça faisait très longtemps que je n'avais pas vu ce genre de chose sur un réseau "normal" et sur ce forum c'est rare de devoir sortir tcpdump/wireshark pour faire un diag. C'est toujours instructif.

[filoo]

J'ai suivi ce post depuis son début sans pouvoir donner un coup de main et tout ce que j'ai lu me fait sourire (amicalement) parce que je ne pipe pas grand chose.
J'ai simplement compris la fin : ça fonctionne maintenant, ce n'est pas optimal mais ça fonctionne. Bravo Fenrir