Accès http sur ports autres que 80 impossible depuis un seul endroit…

[Tazintosh]

Bonjour à tous.

Je suis confronté à un problème particulièrement étrange, tout du moins en ce qui me concerne :
—Uniquement depuis chez mes parents, en aquitaine—, je ne peux accéder à mon serveur sur (à première vue), tout port http autre que le 80. Explications :

Configuration de mon server :
• Fibre SFR sur Box NB6 (NAT seulement)
• Time Capsule (DHCP seulement)
• Mac mini, Mac OS 10.10.4 Server
• NAS Qnap

Depuis de nombreux endroits (Australie, Allemagne, Autres villes de France, etc. testé grâce à des amis), l’accès à http://domaine.com est parfaitement fonctionnel, idem pour un l’accès à l’admin web du NAS sur 9999. Les connections en https, afp, sftp / ssh, etc. fonctionnent, idem pour des services et ports moins courants, même topo pour les sous domaines (qui pointent vers la même ip publique), tels que sous.domaine.com. Ce qui semble prouver que je n’ai aucun problème de DNS, de redirection de ports ou autres. Le domaine a été acheté chez OVH et pointe vers mon IP publique.

Configuration chez mes parents :

• ADSL SFR sur Box NB6 neuve (NAT seulement et changée en vain il y a trois jours, pour tenter de résoudre le problème, il avait une NB4)
• Time Capsule (DHCP seulement)

Depuis chez eux, il est possible d’accéder sans problème et depuis tout périphérique (Mac bureau, portable, iOS) ou navigateur à :
• http://domaine.com, http://sous.domaine.com
• afp://domaine.com, afp://sous.domaine.com
• sftp / ssh://domaine.com, sftp / ssh://sous.domaine.com
• etc.

Mais impossible d’accéder à :
• http://domaine.com:9999, http://sous.domaine.com:9999
• https://domaine.com, https://sous.domaine.com

Page blanche, chargement sans fin (pas de timeout). Les requêtes arrivent bien sur le serveur (vu en direct ou via les logs. Exemple parmi d’autres, Safari chez mon père va changer l’URL de domaine.com:9999 à http://domaine.com:9999/redirect.html?count=0.123456789, ce qui prouve bien que la requête est arrivée et q’un début de réponse a été retourné).

Mes propres matériels (portable, iPhone, iPad, etc.) rencontrent le même problème alors que bien évidement, ça n’a jamais été le cas auparavant, sur un autre réseau.

À ce stade, je vous vois venir mais bougez pas, j’ai plus intéressant.
Si j’utilise le VPN en mode « envoyer tout le traffic » du Mac mini, pas mieux.

Mais si j’utilise la connexion (sans VPN) 3G des iPhones (partagée notamment pour les Mac), tous les périphériques peuvent désormais accéder aux services et ports http(s) qui ne fonctionnaient pas avant.

Si je me connecte à mon VPN payant en mode « envoyer tout le traffic », tout marche.

Ce que j’ai tenté (parmi ceux que je vais certainement oublier)
• Sortir la Time Capsule de mes parents du schéma et laisser la Box faire le NAT et le DHCP.
• Changer les DNS des périphériques, notamment du iMac à partir duquel je teste, et faire un flush.
• Je n’ai vu aucune règle de blocage sur le Mac mini ou la box fibre.

Voilà, je suis un peu perdu, j’ai du mal à cerner comment « tout » puisse marcher de « partout » ailleurs, alors que depuis la connexion de mes parents, seul les connexions http sur un port autre que 80 ne passent pas Oo

Toute aide serait vraiment la bienvenue.

Merci d'avance.

 

[BlueG3]

je suppose que pour la partie serveur tu as bien vérifié
IPv4 ou IPv6 et les classes pour le filtre et IP concernées , cad ne pas avoir à la fois 192.168.0.x et 192.168.1.x ....

 

[Tazintosh]

Bonjour et merci de la réponse BlueG3.

Malheureusement, je ne comprends pas comment la classe IP que je choisi pour mon réseau local (celui ou le serveur réside), puisse avoir un quelconque lien avec l'accès à mon serveur depuis l'extérieur (via l'IP publique).
Comme je le disais, —tous— les services fonctionnent, et ce, de n'importe où, sauf depuis chez mes parents, et —uniquement— en protocole http sur port autre que 80.

 

[Polo35230]

Bonjour,

Pas simple, le pb.
On peut penser qu'il est du côté de vos parents, bien sûr.
Perso, je ne crois pas à un pb de NAT-PAT de votre côté, puisque tt marche (sauf à partir de chez vos parents).
Tjs pour moi, pas de pb également de NAT-PAT chez vos parents, puisque c'est une connexion sortante.
Utilisez vous la redirection de domaine chez OVH?

Je ferais plusieurs tests à partir d'un Mac chez vos parents:
-Un nslookup domaine.com pour voir quels sont les DNS qui répondent (ceux d'OVH ou de SFR), et récupérer votre adresse IP publique.
-Un telnet VotreAdresseIpPublique 80 (pour confirmer que la connexion est OK sur le serveur via le port 80; On doit avoir "connected to")
-Un telnet VotreAdresseIpPublique 9999 (pour voir si la connexion se fait bien sur le port 9999 sans passer par un DNS)
-Un telnet domaine.com 9999 (même chose que ci-dessus, mais en passant par un DNS)

Après, si ces tests ne donnent pas de piste, il faudra peut-être faire un tcpdump (du côté de vos parents) sur le port 9999, puis faire une connexion sur le serveur. On aura alors une trace de la connexion.
Voir la commande ci-dessous:
sudo tcpdump 'tcp port 9999'

 

[Tazintosh]

Bonjour Polo35230,

Navré pour le délai de ma réponse, je suis actuellement en déplacement en Allemagne (d'où j'accède à mes services d'ailleurs ^^)
J'utilise la redirection OVH de la manière suivante :

domaine.com. ---------- TTL 0 ---------- Type A ---------- MonIPPublique
sous.domaine.com. ---- TTL 0 ---------- Type CNAME ---- domaine.com.

Je ferai les tests proposés dès que possible. Merci !

 

[Tazintosh]

Bonsoir Polo35230

Bon, ça y est, j'ai 5 minutes (après 1,5 mois ^^), mais surtout, je suis chez mes parents (je pars demain).

Alors, le nslookup domain.com donne le résultat suivant :
Server: IP de leur box
Address: IP de leur box#53
Non-authoritative answer:
Name: domain.com
Address: 12.34.56.78 (IP publique de mon serveur)

Telnet sur port mon IP publique, port 80
Trying 12.34.56.78 (IP publique de mon serveur)...
Connected to 78.56.34.12.rev.sfr.net.

Telnet sur port 9999 retourne la même réponse.
Telnet sur domain.com 9999 retourne la même réponse.

Tout cela semble confirmer ce que je disais au tout début, à savoir que les requêtes arrivent bien au serveur et que celui-ci répond (redirection d'URL etc.)
Petite nouveautés depuis la dernière fois cependant (seules différences pour nous : le passage à El Capitan) :
• L'accès en https fonctionne —de temps en temps—, ça semble carrément aléatoire. Bon je ne peux toujours pas inscrire les machines de bureau sur le gestionnaire de profils Apple, mais j'ai pu enroler tous les périphériques iOS de mes parents (ce qui était impossible avant oO)
• Certains services sont accessibles sur des ports 45XXX & co, mais d'autres non, ex. 32XXX

Le tcp dump donne la sortie suivante :

tcpdump: data link type PKTAP
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on pktap, link-type PKTAP (Packet Tap), capture size 262144 bytes
20:18:40.048350 IP 78.56.34.12.rev.sfr.net.http-alt > IP.LOCALE.DE.MES.PARENTS.64111: Flags [F.], seq 583228941, ack 3819037000, win 243, options [nop,nop,TS val 1632034283 ecr 810556229], length 0
20:18:40.048433 IP IP.LOCALE.DE.MES.PARENTS.64111 > 78.56.34.12.rev.sfr.net.http-alt: Flags [.], ack 4294964470, win 4119, options [nop,nop,TS val 810570853 ecr 1632019153,nop,nop,sack 1 {4294965910:0}], length 0
20:19:49.092700 IP IP.LOCALE.DE.MES.PARENTS.64111 > 78.56.34.12.rev.sfr.net.http-alt: Flags [F.], seq 1, ack 4294964470, win 4119, options [nop,nop,TS val 810638599 ecr 1632019153,nop,nop,sack 1 {4294965910:0}], length 0
20:19:51.229437 IP IP.LOCALE.DE.MES.PARENTS.64111 > 78.56.34.12.rev.sfr.net.http-alt: Flags [F.], seq 1, ack 4294964470, win 4119, options [nop,nop,TS val 810640712 ecr 1632019153,nop,nop,sack 1 {4294965910:0}], length 0
20:19:55.365606 IP IP.LOCALE.DE.MES.PARENTS.64111 > 78.56.34.12.rev.sfr.net.http-alt: Flags [F.], seq 1, ack 4294964470, win 4119, options [nop,nop,TS val 810644738 ecr 1632019153,nop,nop,sack 1 {4294965910:0}], length 0
20:20:03.421224 IP IP.LOCALE.DE.MES.PARENTS.64111 > 78.56.34.12.rev.sfr.net.http-alt: Flags [F.], seq 1, ack 4294964470, win 4119, options [nop,nop,TS val 810652590 ecr 1632019153,nop,nop,sack 1 {4294965910:0}], length 0
20:20:12.541076 IP IP.LOCALE.DE.MES.PARENTS.64119 > 78.56.34.12.rev.sfr.net.http-alt: Flags [S], seq 3576136734, win 65535, options [mss 1460,nop,wscale 5,nop,nop,TS val 810661520 ecr 0,sackOK,eol], length 0
20:20:12.578294 IP 78.56.34.12.rev.sfr.net.http-alt > IP.LOCALE.DE.MES.PARENTS.64119: Flags [S.], seq 2943125089, ack 3576136735, win 28960, options [mss 1452,sackOK,TS val 1632126816 ecr 810661520,nop,wscale 7], length 0
20:20:12.578355 IP IP.LOCALE.DE.MES.PARENTS.64119 > 78.56.34.12.rev.sfr.net.http-alt: Flags [.], ack 1, win 4140, options [nop,nop,TS val 810661555 ecr 1632126816], length 0
20:20:12.579750 IP IP.LOCALE.DE.MES.PARENTS.64119 > 78.56.34.12.rev.sfr.net.http-alt: Flags [P.], seq 1:467, ack 1, win 4140, options [nop,nop,TS val 810661556 ecr 1632126816], length 466: HTTP: GET / HTTP/1.1
20:20:12.625295 IP 78.56.34.12.rev.sfr.net.http-alt > IP.LOCALE.DE.MES.PARENTS.64119: Flags [.], ack 467, win 235, options [nop,nop,TS val 1632126861 ecr 810661556], length 0
20:20:12.632891 IP 78.56.34.12.rev.sfr.net.http-alt > IP.LOCALE.DE.MES.PARENTS.64119: Flags [P.], seq 1:653, ack 467, win 235, options [nop,nop,TS val 1632126862 ecr 810661556], length 652: HTTP: HTTP/1.1 200 OK
20:20:12.632951 IP IP.LOCALE.DE.MES.PARENTS.64119 > 78.56.34.12.rev.sfr.net.http-alt: Flags [.], ack 653, win 4119, options [nop,nop,TS val 810661606 ecr 1632126862], length 0
20:20:12.640974 IP IP.LOCALE.DE.MES.PARENTS.64119 > 78.56.34.12.rev.sfr.net.http-alt: Flags [P.], seq 467:986, ack 653, win 4119, options [nop,nop,TS val 810661614 ecr 1632126862], length 519: HTTP: GET /redirect.html?count=0.2805574198719114 HTTP/1.1
20:20:12.690897 IP 78.56.34.12.rev.sfr.net.http-alt > IP.LOCALE.DE.MES.PARENTS.64119: Flags [P.], seq 2093:3479, ack 986, win 243, options [nop,nop,TS val 1632126922 ecr 810661614], length 1386: HTTP
20:20:12.690948 IP IP.LOCALE.DE.MES.PARENTS.64119 > 78.56.34.12.rev.sfr.net.http-alt: Flags [.], ack 653, win 4119, options [nop,nop,TS val 810661662 ecr 1632126862,nop,nop,sack 1 {2093:3479}], length 0
20:20:19.178316 IP IP.LOCALE.DE.MES.PARENTS.64111 > 78.56.34.12.rev.sfr.net.http-alt: Flags [F.], seq 1, ack 4294964470, win 4119, options [nop,nop,TS val 810668095 ecr 1632019153,nop,nop,sack 1 {4294965910:0}], length 0
20:20:27.702099 IP 78.56.34.12.rev.sfr.net.http-alt > IP.LOCALE.DE.MES.PARENTS.64119: Flags [F.], seq 3479, ack 986, win 243, options [nop,nop,TS val 1632141937 ecr 810661662], length 0
20:20:27.702143 IP IP.LOCALE.DE.MES.PARENTS.64119 > 78.56.34.12.rev.sfr.net.http-alt: Flags [.], ack 653, win 4119, options [nop,nop,TS val 810676406 ecr 1632126862,nop,nop,sack 1 {2093:3479}], length 0
20:20:42.078162 IP IP.LOCALE.DE.MES.PARENTS.64119 > 78.56.34.12.rev.sfr.net.http-alt: Flags [F.], seq 986, ack 653, win 4119, options [nop,nop,TS val 810690428 ecr 1632126862,nop,nop,sack 1 {2093:3479}], length 0
20:20:42.120024 IP 78.56.34.12.rev.sfr.net.http-alt > IP.LOCALE.DE.MES.PARENTS.64119: Flags [.], ack 987, win 243, options [nop,nop,TS val 1632156353 ecr 810690428], length 0
20:20:42.120076 IP IP.LOCALE.DE.MES.PARENTS.64119 > 78.56.34.12.rev.sfr.net.http-alt: Flags [.], ack 653, win 4119, options [nop,nop,TS val 810690469 ecr 1632126862,nop,nop,sack 1 {2093:3479}], length 0
20:20:50.586186 IP IP.LOCALE.DE.MES.PARENTS.64111 > 78.56.34.12.rev.sfr.net.http-alt: Flags [F.], seq 1, ack 4294964470, win 4119, options [nop,nop,TS val 810698903 ecr 1632019153,nop,nop,sack 1 {4294965910:0}], length 0
20:21:42.549907 IP IP.LOCALE.DE.MES.PARENTS.64111 > 78.56.34.12.rev.sfr.net.http-alt: Flags [F.], seq 1, ack 4294964470, win 4119, options [nop,nop,TS val 810749887 ecr 1632019153,nop,nop,sack 1 {4294965910:0}], length 0

 

[Polo35230]

Alors oui, le nslookup est bon.
Les telnet sur les ports 80 et 9999 aussi.

Le seul truc curieux, c'est la trace du "telnet domaine.com 9999" et les trois lignes ci-dessous qui correspondent à l'ouverture de session tcp (flags syn, syn ack, ack)
20:20:12.541076 IP IP.LOCALE.DE.MES.PARENTS.64119 > 78.56.34.12.rev.sfr.net.http-alt: Flags ,
20:20:12.578294 IP 78.56.34.12.rev.sfr.net.http-alt > IP.LOCALE.DE.MES.PARENTS.64119: Flags [S.]
20:20:12.578355 IP IP.LOCALE.DE.MES.PARENTS.64119 > 78.56.34.12.rev.sfr.net.http-alt: Flags [.]
Sur cette trace, on voit que côté parents, la demande d'ouverture de session est faite sur le port tcp 8080 (c'est le http-alt), et pas sur le port 9999. Pas normal…
Le numéro de port tcp destination a donc été changé.
Il faudrait peut-être envoyer la trace à OVH en leur demandant comment il est possible qu'un telnet sur le port 9999 passe sur le port 8080 après redirection.

Le mystère, c'est: Pourquoi c'est bon à partir de l'étranger?
Il faudrait peut-être faire un tcpdump à partir de l'étranger pour voir si le port destination est bien 9999
Pas simple…