Acceès WES à distance derrière modem 4G

Bonjour,

Concernant votre configuration d’un serveur VPN externe pour faire du pear to pear, je pense que cela serait possible d’installer ce type d’interface, si vous achetez un nom de domaine « toto.com » et si vous louez un petit serveur linux chez un hébergeur comme chez AMEN. Par contre je ne connais pas de serveur VPN en ligne qui permettrait ce genre de connexion.

Mais plus simple et moins cher, vous pouvez vous procurer une carte SIM 4G IP FIXE qui permet d’obtenir une adresse IP fixe sur le réseau 4G au choix. Ce type de carte SIM IP Fixe est utilisé plus particulièrement par certaines Sté.

Vous avez aussi la possibilité de souscrire à l’offre de la 4G Bbox de chez Bouygues Télécom qui est pratiquement le seul FAI à fournir une SIM 4G incluant une IP Publique d’office. Mais cette config ne permet pas au Modem d’être Nomade.

Cette Ip publique est toutefois dynamique mais il vous est facile d’y faire des accès externes via un service DynDNS, exemple : dynv6, Securepoint DynDNS, DynDNS Service, ClickIP, No-IP. Le Service DynDDNS se synchronise sur les changements de l’IP du FAI. Certains de ces Services DynDDNS sont gratuits, le meilleur à mon avis est le Securepoint DynDNS.

Par ailleurs il faut vous assurez que votre Modem/Routeur inclus la config du service DynDNS et permet aussi la redirection des flux entrant vers l’Ip local du WES via une config DMZ ou mieux la redirection du flux entrant associé à un n° de port au choix vers le port 80 et IP du WES via une config NAT.

Il faut voir la meilleure et la plus simple des solus en fonction du côut. Je pense que l’offre 4G Bbox de chez Bouygues Télécom répond aux critères si  la config de votre Routeur permet les redirections et la config DynDNS.

Si vous faites le pas avec la 4G Bbox, assurez vous que l’IP dynamique est bien fourni et voir si vous pouvez utiliser votre matériel en lieu et place au modem normalement fourni et loué par Bouygue.

Cdt

Bonjour,

Peut être connaissez vous ce site qui pourrait répondre à votre configuration 4G avec SFR en fournissant une IP Publique Fixe :
https://airmob.net/nouvelle-option-disponible-une-adresse-ip-publique-fixe-pour-votre-routeur-4g/

En cherchant les spécifications de votre petit routeur gl-mt300n, j’ai trouvé ce site qui donne quelques spécifications et configuration du routeur modèle gl-mt300n-V2. Peut être trouverez vous une aide pour solutionner votre problème :
https://www.fanjoe.be/?p=3018

A priori vous pouvez configurer le routeur en mode Bridge ou Router. D’après le site, en mode Router, le NAT, le firewall et le serveur DHCP sont activés. En mode bridge le router est transparent et le port WAN devient un port LAN.

N’ayant pas de 4G avec IP pour utiliser le mode Bridge, je suppose que vous avez configuré votre routeur en mode Router afin de bénéficier de la redirection NAT, du serveur DHCP et du Firewall. Je suppose aussi que vous avez configuré le WES en mode DHCP et c’est votre routeur en mode serveur DHCP qui lui fourni son IP locale. Je suppose que vous avez configuré le serveur DNS du routeur pour faire pointer le nom du WES sur son IP locale. Et pour finir je suppose que vous avez configuré le NAT pour faire pointer le Nom du DDNS du Cloud de gl-inet vers l’IP du WES.

A priori votre routeur possède le WIFI. Avez vous essayé localement de vous connecter au WIFI du routeur avec un smartphone par exemple et ensuite tester la connexion HTTP au WES via son nom DNS et/ou IP local. Si la connexion WIFI fonctionne localement, alors l n’y a pas de raison que les appels entrant avec le nom du DDNS du Cloud configuré dans le NAT, n’arrive pas jusqu’au WES via le WAN. Bien sur il faut regarder si le FireWall ne bloque pas les Ports utilisés (80).

Cdt

Re: Bien sur pour joindre le WES depuis internet, il faut l’appeler avec le nom DDNS de votre Cloud gl-inet > exemple xxxxx.gl-inet.com

Re: Afin d’éviter d’avoir un conflit en Entrée du routeur avec le port 80, vous pouvez choisir un Port spécifique pour faire la redirection du flux Http du DDNS cloud via le NAT du Routeur et le rediriger en arrière vers le Port 80 et n° IP local du WES.

Exemple d’appel du WES depuis internet avec le choix du Port 9100 : xxxxx.gl-inet.com:9100/

Exemple d’envoi de requête au WES avec le Port 9100 : http://login:password@xxxxx.gl-inet.com:9100/?rl1=ON

Je suis désolé mais vos réponses sont incompréhensible. Il faut éviter de faire un Copie/Coller direct du Blog, car vous copier tous les TAG du Blog en même temps, Passez par un éditeur (bloc-note) intermédiaire pour ensuite recoller le texte dans votre réponse. Cela élimine ces Tags.

Comment avez vous configuré le routeur ? en mode Bridge ou Router ? Il faut qu’il soit en mode Routeur ! si vous avez établie une connexion en Mode Bridge, comme votre 4G n’a aucun IP à offrir, votre WES ne pourra jamais se connecter.

Votre Cloud gl-inet semble être un Gros Serveur VPN avec lequel vous établissez une connexion Type Tunneling (ITP) avec votre Routeur via le protocole OpenVPN ou équivalent (firmware) . Le routeur une fois lié (Bind) au serveur Cloud lors de la config, une connexion Tunnel est établie et prête à transmettre des Flux TCP à la demande.

Lors de votre config, vous avez du avoir une n° ID qui identifie votre Routeur au niveau du Cloud. Un DDNS (DynDNS) est construit en relatif à cette Identification. C’est le nom du domaine de votre connexion à votre Routeur via le Cloud. Normalement en faisant un accès internet via ce DDNS vous devriez tomber sur votre Routeur.

La configuration NAT normalement vous permet de faire une redirection des flux vers l’IP local du WES, Ip attribué par le serveur DHCP du Routeur. En changeant le Port d’appel en amont vous évitez des conflits éventuel avec le port 80. Ceci est vrai si votre routeur présente une page Admin ou WEB à l’adresse d’appel du DDNS sur le port 80 depuis internet.  Vérifier si le Parefeu du routeur n’empêche pas les redirections des Ports utilisés.

Bon courage

Cdt

Bonjour,

Je pense que vous avez trouvez indirectement, pourquoi cela ne peut pas fonctionner tel que vous connectez votre Routeur GLInet.

Votre Gl-inet est un Routeur Propriétaire associé à un Fabriquant qui en parallèle à son Matériel, a mis en place et gère un Cloud VPN via internet qui permet de faire communiquer via un protocole de Tunneling VPN son propre matériel. Le Firmware propriétaire installé dans votre Routeur GL_Inet est étudié pour réaliser cette communication avec son Propre Cloud.

Normalement le port WAN de votre Routeur GI_inet devrait être directement connecté en sortie du WAN d’un Modem 4G en l’occurence votre Huawei et non sur une des connexions LAN RJ45 du Routeur associé au 4G Huawei. Le routeur de votre 4G Huawei n’est pas transparent et bloque tous les échanges entre le Cloud et votre GL_Inet devenu Client du Routeur en amont.

Il faudrait faire l’inverse pour que cela fonctionne. Votre GL-Inet devrait être raccordé sur le WAN du Modem 4G et tous vos Clients Lan raccordés en sortie du RJ45 du GLInet via un Switch éventuellement. Le Routeur du 4G Huawei est du coup inutile. Si vous avez un moyen de faire un By-Pass type Y du WAN du Modem 4G alors peut être pourriez partager les échanges du WAN entre le Routeur du Huawei et le GL_Inet.

Une solus serait de remplacer votre Modem / Routeur 4G Huawei par une Clé USB 4G puisque le GLInet permet semble t’il ce genre de connexion. Votre réseau local serait alors piloté par le Serveur DHCP du Gl-inet, Un Switch permettrait d’étendre le nombre de sorties RJ45 si nécessaire. Vous pourriez alors via le NAT du Gl-inet, rediriger les Flux entrant du DDNS Cloud associé à un port spécifique ex : 9100 vers le WES et le port 80. Il faudrait bien sûr autoriser le Firewall du GL.Inet, toutes les redirections dans les deux sens. Il faut voir aussi la Charge et taux de transfert utile du GL.Inet côté LAN.

Cdt

Re: Autre Solus serait de remplacer votre Modem / Routeur 4G par un simple Modem 4G avec sortie WAN ou comme je l’ai indiqué, utiliser une Clé USB 4G si votre GLInet le permet comme cela est indiqué dans sa Doc et d’après ses menus de config.

Bonjour,

Votre essais de connexion du Gl.Inet en USB à votre Tel Mobil semble pertinent et logiquement devrait fonctionner !?, votre téléphone devrait se comporter comme un modem d’accès 4G en principe !?….

Avez vous essayé l’autre méthode qui consiste à connecter le GLInet en mode wifi à votre Tel. Mobil configuré en point d’accès wifi ? Possible que ce mode soit plus transparent !?…

Peut être qu’il est impossible de réaliser une Connexion 4G sans IP au DDNS Cloud  ?

Je pense qu’il serait judicieux de contacter par mail le Support Technique de GL.Inet : support@gl-inet.com.

Vous pourriez exposer votre situation (Cnx 4G sans IP fixe) , décrire vos besoins et leur demander comment réaliser l’accès à un Client ( WES ) par le biais du DDNS Cloud  GLInet ( via modem 4G, Tel.Mobil, etc) . Je suis persuadé qu’ils pourront vous aider et donner une solution de config.

La traduction en ligne du Français vers l’Anglais via Google pourrait vous aider à rédiger votre texte si vous ne maîtrisez pas l’anglais. L’inverse est vraie aussi !

En tout cas, j’ai découvert grâce à vous ce tout petit Routeur qui semble être un petit Bijou pleins de possible ! Je n’en ai pas l’utilité pour l’instant, mais j’ai envie de l’acheter pour en savoir plus.

Tenez nous au courant, si une solution est trouvée !

Pour terminer, en principe les FAI se partagent les emplacements d’antennes 3G/4G. Etes vous sûr, que seul SFR vous permet l’accès à la 4G ? Avec Bouygues vos problèmes seraient réglés grâce à leur offre 4G avec IP dynamique de façon implicite et forfait équivalent.

Cdt

Bonjour,

J’avais bien décrypté vos hiéroglyphes :

« Sinon effectivement, je viens de vérifier sur Cartoradio le pylône sur lequel il y a SFR affiche aussi une antenne Bouygues. Et comme le nom qui apparaît est : N° identification : 1782494 – Description du support : Pylône autostable / 14m / SFR , j’en déduis que l’antenne est partagée SFR/Bouygues. Cela peut être une solution avec IP dynamique si je ne réussis pas avec mes mini-routeur. Super conseil, merci »

ça, c’est une bonne nouvelle pour vous !

J’ai péché par curiosité et j’ai finalement passé commande de votre routeur modèle GL-iNet GL-MT300N-V2(Mango) .

Concernant votre problème de blocage après avoir rentré vos logins pour vous connecter au WES, cela ressemble à un problème plus ou moins identique, qu’un autre personne sur ce site m’a fait part, il y a moins d’une heure et on en n’a déduit que son logins et mots de passe étaient composés de caractères spéciaux (accent etc) qui pourraient dans votre cas ne pas être traduit de façon transparent par le Cloud vers le WES.

Si c’est le cas pour vous, reformater votre login et password dans le WES avec des caractères normaux (Lettres minuscules) et sans accents. Possible que votre Pb vienne de cela, il faut le tester !

Cdt

Essayez de rentrer votre login directement dans la structure de l’adresse du WES : http://login:password@IP-ou-NomDomaineWES:80/

Essayez de passer par FTP, FileZilla ?

Il faudrait aussi voir si un des Parre-feu des GL.Inet ne vous bloque pas ?

Re: Je ne sais pas quel navigateur vous utilisez, mais essayez d’ouvrir la console Web depuis le menu des outils de développement et rentrer dans l’onglet des transactions Réseau. Normalement vous allez pouvoir lire le compte rendu de la tentative de connexion au WES et son N° d’erreur vous donnera peut être une piste ?

Code 500 : Erreur interne du serveur
Code 502 : Mauvaise passerelle
Code 503 : Service indisponible
Code 504 : Temps d’attente expiré

Re: Désolé mais les idées fusent !

Possible que votre Site Cloud transporte le flux HTTP (port 80) en mode sécurisé HTTPS (port443) et que ce port 443 ne soit pas autorisé de redirection dans le NAT côté GL.Inet du WES ?

Bonsoir,

Votre message d’erreur en appel du WES en HTTP,  semble indiquer peut être que le WES se plante et reboot ?

Avec la Console WEB de Chrome vous pouvez voir les événement et Status des réponses Réseau.

Pour lancer la console faire F12. Une fois la console ouverte cliquez en haut dans l’onglet NETWORK. Complètement à gauche sur la rangé juste en dessous du bandeau Onglet vous trouver un petit rond, s’il est noir cliquer pour le mettre en rouge, c’est le play/pause de l’affichage des événement. En rouge l’ensemble est en PLAY.

Dans la grande fenêtre en dessous faites un clic droit puis clic sur Header Option. Vous avez une liste d’options à sélectionner. Chaque option sélectionnée va créer une colonne dédiée. Il faut au minimum : Name, Path, Url, Status, Remote Address, Type, Initiator, Eventuellement Size et Time. A fur et à mesure des sélections, des colonnes  apparaissent en relatif.

Toujours dans la suite de ces options à sélectionner vous trouvez response Header, c’est un menu qui ouvre une petite fenêtre. Sélectionner Connection et Server.  Ensuite, toujours dans la liste des sélections vous trouvez en bas Waterfall. Idem cela ouvre une autre fenêtre et vous sélectionnez Response Time.

Les Codes de Réponses aux requêtes et appels  Http sont lus dans la colonne Status.

Essayez d’agencer vos colonnes. elle pourront être redimentionnée en sélectionnant les tirets entre chaque Texte des colonnes.

Il suffit maintenant de lancer votre Connexion au WES, Normalement vous devriez voir toutes les transactions se réaliser au fil de l’eau dans la grande fenêtre au milieu. Chaque colonne va se remplir de leur spécificité.

Si les échanges se font du haut vers le bas de la grande fenêtre, descendre la barre de l’acensseur située à droite complètement vers le bas et vous faîtes l’inverse si les échanges apparaissent au fil de l’eau du bas vers le haut de la fenêtre.

Vous pouvez arrêter le défilement des lignes en cliquant sur le point rouge (Play/pause) et reprendre en cliquant lorsqu’il est noir.

Dans la colonne à droite Waterfall, vous avez des Graphs de couleur qui vous montre les temps d’accès pour chaque requêtes. En passant la sourie sur une des barre de couleur, on vous les infos et timing plus complète.

Voila peut être que vous pourrez trouvez le Code erreur renvoyé à la demande de connexion du WES.

Trouvez en pièce jointe une image de la page de Chrome avec sa console WEB ouverte.

Cdt

Re: Redirection en HTTPS port 443 vers Port 80 en interne.

Bonjour,

J’ai reçu mon tout petit routeur modèle GL-MT300N-V2. Je vous donne mon retour d’expérience.

J’ai connecté la RJ45 WAN du GL.Inet sur une des RJ45 LAN de ma BOX ( FAI ).
J’ai connecté un PC via le WIFI en tant que Client WIFI du GL.Inet. j’accède sans problème au menu Admin via l’adresse 192.168.8.1. Le GL.Inet lui à fourni l’IP local 192.168.8.101

J’ai configuré la config Câble (WAN) du GL.Inet sur DHCP, MA Box lui à donné l’IP 192.168.1.39. Via l’ADMIN du GL.Inet, J’ai fait la mise à jour de son Firmware à la dernière version 3.102.

Comme j’ai un 2eme WES qui me sert de test,  j’ai configuré sa propre config Réseau en mode DHCP=ON. J’ai connecté la RJ45 du WES à la prise RJ45 LAN du GL.Inet. Le WES à reçu l’IP locale du GL.INET 192.168.8.177. Dans la config Client du GL.Inet j’ai activé la mise en Static de cette IP 192.168.8.177 du WES avec le bouton de droite mis en Vert.

Dans ma BOX j’ai forcé l’IP locale 192.168.1.39 fourni au GL.Inet en Mode Static afin d’être assuré d’avoir toujours cette IP affecté au GL.Inet depuis ma BOX. Toujours dans ma Box, j’ai configuré le NAT afin de laisser passer le Port Ext: 1900 vers le Port Int. 9100 associé à l’IP et MAC du GL-Inet. soit IP 192.168.1.39 et Mac xx:xx:xx:xx:xx:xx

Dans la config Pare-Feu du GL.Inet, dans la rubrique Port Forward, J’ai autorisé pour l’IP local 192.168.8.177 (WES) la redirection du Port 1900 vers le Port 80.

Toujours dans le Pare-Feu du GL.Inet, dans la rubrique Port entrant sur le routeur, j’ai autorisé les Port 80. 443, 22 et 9100 comme Port Entrant. Je n’ai pas configuré le DMZ qui permet toutefois un trafic dans les deux sens et sans dicris des Ports.

Dans le menu Application du GL.Inet, rubrique Accès à Distance, J’ai Activé le DDNS avec les protocole HTTP, HTTPS, SSH. J’ai testé la liaison DDNS par Test DDNS du bandeau Texte bleu.

Il trouve l’IP Dynamique Publique de ma BOX mais m’affiche comme Vous le message :  Votre DDNS est réglé en tant que 176.184.xxx.xxx. Mais ce routeur est derrière NAT ou vous n’avez pas d’adresse IP publique.

J’ai revérifié toute ma config, et comme vous je ne comprends pas pourquoi cela ne répond pas au TEST vue que tout est bien configuré.
J’ai vue juste au dessus du DDN Dynamique la config Gestion du Cloud. Je n’ai pas activé cette gestion Cloud mais dans le texte en bleu de cette rubrique on me dit que mon identifiant d’appareil est: wqxxxxx.

Juste par curiosité j’ai voulu tester le DDNS du GL.Inet et j’ai lancé depuis mon navigateur : http://wqxxxxx.glddns.com:9100/

Et Plouf je tombe sur le login du WES, je me logue et j’accède au WEB du WES : Cela Fonctionne !

Donc je déduis que le message rendu lors du TEST DDNS qui spécifie : Mais ce routeur est derrière NAT ou vous n’avez pas d’adresse IP publique.  veut seulement dire que logiciel de l’ADMIN du GL.INET n’arrive pas à remonter le NAT du Routeur GL.Inet ( port 1900 > 80 ) ainsi que le NAT de ma Box ( port 1900 > 1900 )

J’ai relue la Doc du GL.Inet est on peut lire en tout petit dans une image de configuration du DDNS que pour faire fonctionner le DDNS il faut une adresss IP Publique.

Note : You have to have an Internal Public IP address to use the Dynamic DNS. If this router is behind NAT you may need to set up port forward in you ISP router.

Cela veut dire que le DDNS du GL.Inet n’est pas un Serveur VPN comme je le supposais mais un Serveur de DynDNS dédié au matériel de GL.Inet comme l’est NO-IP.

Donc c’est bien la gestion GLOUD qui permet les liaisons VPN.

Je ne peux pas essayer ce Cloud car je n’ai pas deux GL.Inet. Mais je pense que votre Pb avec le protocole HTTP qui ne passe pas est du à la config et autorisation du Port 80, dans vos divers Configs.

A moins que le Cloud utilise le Port 443 (HTTPS) pour faire la passerelle (Tunneling) entre les deux Clients GL.Inet et dans ce cas il faut convertir le protocole HTTPS en HTTP. (Il faut voir les Codes retour des transactions)

En tout cas ce petit Routeur, est vraiment génial et permet pleins de configs. Comme vous l’avez démontré il peut aussi utiliser la 4G depuis un Tel: Mobil pour faire un petit réseau local et se connecter à internet en Nomade avec un PC dans le cas ou le WIFI ou Hot Spot Wifi n’existe pas.

Cdt

RE: je corrige : Dans mon texte j’ai mélangé le Port 9100 avec 1900 ?? étourderie . C’est bien le Port 9100 qu’il faut lire et que j’ai choisi comme Port de redirection.

Correction : Dans la config Client du GL.Inet j’ai activé la mise en Static de cette IP 192.168.8.177 du WES avec le bouton de droite mis en Vert.

Surtout ne pas faire, j’avais mal compris, cela BLOC la liaison !! Mais cela n’est pas visible de suite ?

Par ailleurs, j’ai remarqué que toute la config n’est réellement prise en compte qu’après avoir coupé le 5 volt quelques seconde et au redémarrage après avoir fait un Reset avec le bouton sur le côté du GL.Inet. ??

RE: lors d’un de vos essais vous avez mentionné :

« Cependant quand j’active le DDNS sur ce mini-routeur j’obtiens le message suivant :  » Votre DDNS est réglé en tant que 81.185.xxx.etc – Mais ce routeur est derrière NAT ou vous n’avez pas d’adresse IP publique » . Et la conséquence est, je pense, que xxxledevice.gl-inet.com ne marche pas. »

Mais voila ! Comme vous j’ai le même message, mais le routeur trouve bien une IP (xx.xx.xx.xx. comme chez vous) et malgré la suite du message, la liaison fonctionne avec le domaine http://wqxxxx.glddns.com, Si bien sur les ports sont bien ouvert en Flux entrant dans la Config du Pare-FEU de GL.Inet et dans votre BOX ou Mobil  ( voir ma config Port et redirections )

C’est bien glddns.com qui faut utiliser comme Domaine DDNS et non gl-Inet.com.

Donc je pense que vous n’avez pas eu la même curiosité de tester comme moi la liaison, http://xxxledevice.glddns.com/,  pour voir si cela fonctionne malgré la suite du message qui spécifie « Mais ce routeur est derrière NAT ou vous n’avez pas d’adresse IP publique »

cdt

Re: Un complément d’info. Je pense que vous l’avez vue, au chapitre 3 de la config DDNS dans la DOC du GL.Inet, on vous indique
que vous pouvez tester votre DDNS afin de voir s’il est opérationnel avant même de le configurer.

Depuis votre PC qui doit être un Client du GL.Inet (Wifi ou Lan) , Il suffit d’ouvrir une Console CMD sous Windows ( taper CMD dans la barre de recherche de Windows ) et dans la fenêtre noire ouverte vous tapez : nslookup wqxxxxx.glddns.com 8.8.8.8

ou wqxxxx est votre Identifiant DDNS visible dans le texte de la Config Cloud au dessus de la config DDNS .
La réponse à cette commande devrait être :

Serveur :   dns.google
Address:  8.8.8.8

Réponse ne faisant pas autorité :
Nom :    wqxxxxx.glddns.com
Address:  176.184.xx.xx

Ou Adresse est l’IP Public Dynamique ou l’IP Privé 4G utilisé par le DDNS et dont sa présence confirme que le DDNS est fonctionnel.
Dans le cas contraire vous devriez lire : *** dns.google ne parvient pas à trouver wqxxxxx.glddns.com : Non-existent domain

Si la réponse est positive avec une Adresse IP, alors essayé de configurer à nouveau votre routeur avec le DDNS et ne tenez pas compte du message :  » Mais ce routeur est derrière NAT ou vous n’avez pas d’adresse IP publique  »

J’ai aussi ce message lors du TEST DDNS mais tout fonctionne correctement. Il ne faut pas tenir compte de ce message. ( Possible Bug logiciel de l’Admin ).

Assurez vous de mettre la Config Réseau du WES en Mode DHCP=ON. car s’il est coincé avec une adresse Static comme par exemple 192.168.1.110, votre WES ne répondra pas. Vous pouvez modifier la config réseau du WES directement depuis son fichier de config RESEAU.CFG situé dans le dossier CFG de la carte mémoire (FTP ou Clé USB). Il suffit de mettre la rubrique DHCP=1 dans le Fichier. Par contre il faut rebooter le WES pour que la config soit prise en compte.

Veillez aussi à ouvrir les Ports Utilisés ainsi que les redirections entre la BOX et le GL.Inet et entre le GL.Inet et le WES.

Essayez ma config NAT avec la redirection du Port Entrant 9100 vers le Port Sortant 9100 pour l’IP du GL.Inet dans la config du Routeur de la BOX et configurer la redirection (Onglet Port Forward  )  du Port Entrant 9100 vers le Port Sortant 80 pour l’IP du WES dans la rubrique Pare-Feu du GL.inet.

N’oubliez pas d’ouvrir les Ports 80 , 443, 9100 pour TCP/UDP dans la config : Onglet Port ouvert sur le routeur, toujours dans la rubrique Pare-Feu du GL.Inet.

Si le Pare-Feu du routeur de votre BOX est activé, il faut aussi débloquer et autoriser ces même Port Entrant et Sortant selon la config disponible.

Tester votre liaison avec : http://wqxxxxx.glddns.com:9100/

Je croise les doigts !

Cdt

Re Re: Retour expérience.

Bonjour,

Je reviens sur l’utilisation du service DDNS du GL-MT300N-V2. J’avais cru avoir réussi à faire fonctionner le DDNS du petit routeur GL.Inet en tant que Client LAN du Routeur associé à ma BOX FAI connecté en ADSL et ayant une IP Dynamique Public.

L’appel DDNS http://xxxxyy.glddns.com a bien fonctionné 2 jours mais lorsque j’ai voulu refaire des essais, bizarrement les tentatives de connexions échoues à 80% ? alors que l’IP public de ma BOX n’a pas encore changée ?.

J’ai joint par Mail le service support de GL.Inet pour voir s’il avait un problème avec leur Serveur DDNS. Il me confirme rapidement, sans me donner des explications sur leur Routeur DDNS, que leur petit GL-MT300N-V2 doit être en Frontal en direct sur le WAN du Modem ADSL afin de récupérer l’IP public de l’ADSL et non derrière le Routeur du Modem et dont le serveur DHCP fourni une IP locale ???.

Ils n’ont pas insisté et non pas donné d’explication sur le fait que cela à pu fonctionner un moment et presque plus maintenant ! Echange mail pas très ouvert au dialogue !

Ce petit routeur GL-MT300N-V2 fonctionne sous une plateforme Linux et c’est la distribution OpenWrt en Open source qui gère l’ensemble des applications de communication. J’ai trouvé le GitHub avec les fichiers sources du firmware OpenWrt de ce petit routeur GL.Inet:  https://github.com/openwrt/packages/.

Les diverses interfaces du GL-MT300N-V2 sont gérées via des applications de OpenWrt sous forme de Plugins élaborés pour la plus part en BASH Script Shell. Voici le dossier des Plugins et applications Réseau: https://github.com/openwrt/net/

On trouve parmi, le package ddns-scripts qui contient les Sources qui gèrent le DDNS du GL.Inet. Ce que ne comprend pas, c’est que la fonction (Script Shell ) dédié à trouver l’IP Public de la BOX FAI, a du mal actuellement à trouver cette IP à travers le Gateway du Routeur de la BOX en tant que Client LAN directement associé au Routeur.

Je sais que l’Interface Linux cURL est installé car certains Scripts OpenWrt l’utilisent. Il y a une commande simple avec cURL qui permet de récupérer très facilement l’IP Public ADSL d’une BOX FAI à travers son Routeur, si vous êtes Client LAN DHCP direct de ce même Routeur.

Si ce Client LAN est un PC ou Micro Contrôleur (Raspberry pi, etc) sous Linux Ubuntu, Débian, Raspbian etc.., avec cUrl installé, comme c’est le cas du GL-MT300N-V2, si vous lancez la commande suivante via un Script Bash ou manuellement depuis une Console :

~# sudo curl http://ifconfig.me

cUrl vous renvoie immédiatement l’IP Public Dynamique de la BOX aussi simplement !

A priori, GL-MT300N-V2 permet de charger ou de modifier un Plugins OpenWrt existant. Je vais voir à étudier comment rajouter ce Test cUrl dans le Script dédié à la recherche de l’IP Public du plugin DDNS et lorsque la recherche de cette IP Public n’aboutit pas avec le Script de base..

J’ai soumis l’idée de rajouter ce simple test Bash cURL aux support Chinois de GL.Inet. Jusqu’à présent ils ne m’ont pas répondu !
Mais à l’origine c’est OpenWrt qui gère mal la recherche de l’IP Public dans son package ddns-scripts dans le cas de figure décrit plus haut.

Cdt

Re Re Re retour expérience.

Encore des bizarreries, l’appel DDNS http://xxxxyy.glddns.com refonctionne parfaitement ce soir ? Est ce dû suite à mes échanges avec les Chinois ? Est ce aléatoire ? La seule chose que j’ai faites c’est d’avoir coupé l’Alim 5volt du Mini routeur pendant 1 heure cet après midi !

Je vais quand même voir à regarder ces Scripts OpenWrt pour mieux comprendre ?

bonjour @fred9274

Je vous donne un suivi lors de mes échanges mails avec les Chinois.

Je leurs avais ouvert l’accès à l’Adim de mon GL-MT300N-V2 depuis internet et depuis le DDNS fonctionne bien. Ils ne m’ont absolument rien dit en retour concernant leur intervention, même pas une confirmation de quoi que ce soit ! seulement j’ai remarqué que le DDNS c’est remis à fonctionner correctement depuis comme au début ?.

Etant curieux de nature j’ai voulu voir s’il m’était possible de trouver ce qu’ils avaient fait ? j’ai installé le plugin OpenWrt SFTP et ouvert le SSH du routeur GL.Inet ce qui me permet maintenant d’accéder à la mémoire interne de mon GL.Inet et voir tous les dossier linux et OpenWrt via BitWise en SSH et FTP.

En regardant la Date des fichiers dans le dossier /etc/ddns Je constate que certains fichiers ont été modifiés à la date de leurs intervention !

Parmi je trouve un fichier de Config qui permet de paramétrer les Options du DDNS. Ils ont mis une Option dans ce fichier de config afin que ‘CURL’ soit utilisé pour les échanges des requête et échanges TCP avec OpenWrt.

Possible que ma proposition d’utiliser ‘CURL’ au lieu de ‘GET’ qui est utilisé par défaut dans OpenWrt leur à mis la puce à l’oreille ?
En tout cas cela fonctionne bien maintenant.

Je ne sais pas si vous êtes revenu de déplacement, mais si vous le voulez, comme votre GL-MT300N distant semble bloquer les appels à votre WES via le GL.iNet GoodCloud avec le port 80 alors que l’accès par FTP semblait fonctionner, je vous propose de rajouter provisoirement dans votre config GoodCloud,  l’ID de mon GL-MT300N-V2 pour Test afin de simuler votre liaison Cloud distant avec mon Routeur GL.Inet provisoirement.

Actuellement j’ai un WES de Test comme Client connecté derrière mon routeur GL.INET, donc vous pourriez retrouver votre config distante.

Etant donné que je ne me sert pas de cet ensemble pour l’instant, vous pourriez plus facilement, étant moi même présent à distance, voir à faire fonctionner votre GL.INET GoodCloud avec mon Routeur.

Dès lors que cela fonctionne, cela vous assure que votre config est bonne et que après il suffit de voir du coté de votre GL.INET distant si vos problèmes d’ouverture du port 80 et/ou 443 sont induit par un pare-feu soit celui de la BOX ou celui du GL.Inet et voir si le port 80 et/ou 443 sont bien ouvert aussi bien dans votre BOX (NAT) et pare-feu de votre GL.Inet distant.

Si vous souhaitez faire les Test évoqués plus haut, J’ai ouvert une boite mail temporaire sur un de mes Serveurs Perso afin d’échanger en dehors du Blog :  contact@cdlogserv.com.

Confirmez moi si cela vous intéresse sur le blog, ensuite je surveillerais ma boite MAil.

Cdt

Bonjour,

Ok pour le retour. Si je résume :

– Vos deux GL.Inet sont connectés par le biais du protocole Site to Site du Cloud. GoogGloud.

– Vous arrivez à vous loguer dans l’admin du GL.Inet distant , vous voyez la présence du WES en tant que Client du GL.Inet. Mais le flux TCP HTTP ne passe pas ! jusqu’au WES

– Dans le menu Firewall du GL.Inet distant, dans la rubrique « Open Port on Routeur » avez vous ouvert les Ports 80, 443 et éventuellement un autre port qui servira plus tard à joindre uniquement le Client WES du routeur comme par exemple le Port 9100.

– Dans votre BOX il est important que le Port 80, 443 et 9100 soit autorisés en Input dans le Pare-feu de la BOX.

– Si vous souhaitez accéder au GL.INT depuis internet il faut rediriger les Ports Input 80 et 443 vers les Ports OutPut 80 et 443 vers l’IP local du GL.INET via le NAT de la BOX

– De même pour joindre le Client WES du GL.inet via le Port 9100,  il faut rediriger le Port input 9100 vers le Port OutPut 9100 vers l’IP local du GL.INET via le NAT de la BOX.

– Il faut rediriger aussi dans le FireWall du GL.Inet dans la rubrique ‘ Port Forward’ le Flux TCP/UDP pour le Port Input 9100 vers le Port OutPut 80 pour l’IP local affecté au WES par le GL.Inet.

Normalement si ces configs sont faites cela devrait fonctionner.

Je suis toujours partant pour faire un test de connexion de votre Cloud via mon GL.Inet. comme nouveau Device.

Lorsque vous serez disponible, On peut poursuivre nos échange via ma boite mail : contact@cdlogserv.com.

Cdt