Un mystère ! Je fais, pour partager des trucs et des machins, un petit
serveur FTP non anonyme hébergé d'athomique façon. J'ai donc mis le nom
de l'URL dans la configuration DNS de mon registrar et il est
nécessaire que je le mette aussi dans le DNS du serveur où il arrive.
Dans les deux cas c'est donc l'URL suivi de l'adresse IP publique. Bien
sûr le routeur-nateur est informé de l'adresse locale où il doit
envoyer les petits paquets destinés aux ports 20 et 21.
Tout cela fonctionne parfaitement pour quiconque d'autorisé qui veut
s'y connecter sauf... pour moi où il m'est même impossible d'afficher
l'arborescence d'un dossier un peu peuplé. Tout se passe comme si il y
avait un conflit si l'IP publique demandeuse et l'IP publique émettrice
est la même.
Bien sûr me connnecter moi-même en FTP public pour aller voir les
fichiers d'un dossier partagé qui se trouve sur la machine voisine est
tordu comme procédé pratique, la démarche était juste de vérification.
Quelqu'un pourrait-il m'expliquer précisément ce qui cloche pour mon
cas particulier ?
Merci pour vos avis éclairés, car là je patauge un peu.
Williamhoustra a utilisé son clavier pour écrire :
Salut l'illustre compagnie.
Un mystère ! Je fais, pour partager des trucs et des machins, un petit serveur FTP non anonyme hébergé d'athomique façon. J'ai donc mis le nom de l'URL dans la configuration DNS de mon registrar et il est nécessaire que je le mette aussi dans le DNS du serveur où il arrive. Dans les deux cas c'est donc l'URL suivi de l'adresse IP publique. Bien sûr le routeur-nateur est informé de l'adresse locale où il doit envoyer les petits paquets destinés aux ports 20 et 21.
Tout cela fonctionne parfaitement pour quiconque d'autorisé qui veut s'y connecter sauf... pour moi où il m'est même impossible d'afficher l'arborescence d'un dossier un peu peuplé. Tout se passe comme si il y avait un conflit si l'IP publique demandeuse et l'IP publique émettrice est la même.
En fait mettre l'adresse publique dans mon serveur DNS était une erreur. Ca fonctionnait parfaitement pour des machines tierces mais ça bloquait d'une façon que je ne m'explique toujours pas (limitation des octets) avec ma machine du domaine.
Donc s'il n'y a rien de changé sur le DNS du registrar (où là il faut bien mettre l'adresse publique, c'est évident), il faut juste renseigner, en interne, le serveur FTP dans la machine serveur. C'est nécessaire car sinon un ping n'aboutit pas. Donc créer une étendue "pandemonium-web.net" distincte de celle de l'intranet et y mettre un hôte [A] avec l'adresse locale 192.168.111.24 (celle sur laquelle sont routés les paquets FTP externes).
Donc la machine locale fonctionne sur cette adresse locale pleinement et rien n'est changé pour l'accès des machines extérieures.
De toute façon ta démarche de vouloir tester ton FTP en simulant un accès externe par l'intermediaire de l'adresse fully qualified
Williamhoustra avait soumis l'idée :
Williamhoustra a utilisé son clavier pour écrire :
Salut l'illustre compagnie.
Un mystère ! Je fais, pour partager des trucs et des machins, un petit
serveur FTP non anonyme hébergé d'athomique façon. J'ai donc mis le nom de
l'URL dans la configuration DNS de mon registrar et il est nécessaire que
je le mette aussi dans le DNS du serveur où il arrive. Dans les deux cas
c'est donc l'URL suivi de l'adresse IP publique. Bien sûr le routeur-nateur
est informé de l'adresse locale où il doit envoyer les petits paquets
destinés aux ports 20 et 21.
Tout cela fonctionne parfaitement pour quiconque d'autorisé qui veut s'y
connecter sauf... pour moi où il m'est même impossible d'afficher
l'arborescence d'un dossier un peu peuplé. Tout se passe comme si il y
avait un conflit si l'IP publique demandeuse et l'IP publique émettrice est
la même.
En fait mettre l'adresse publique dans mon serveur DNS était une erreur.
Ca fonctionnait parfaitement pour des machines tierces mais ça bloquait d'une
façon que je ne m'explique toujours pas (limitation des octets) avec ma
machine du domaine.
Donc s'il n'y a rien de changé sur le DNS du registrar (où là il faut bien
mettre l'adresse publique, c'est évident), il faut juste renseigner, en
interne, le serveur FTP dans la machine serveur. C'est nécessaire car sinon
un ping n'aboutit pas. Donc créer une étendue "pandemonium-web.net" distincte
de celle de l'intranet et y mettre un hôte [A] avec l'adresse locale
192.168.111.24 (celle sur laquelle sont routés les paquets FTP externes).
Donc la machine locale fonctionne sur cette adresse locale pleinement et
rien n'est changé pour l'accès des machines extérieures.
De toute façon ta démarche de vouloir tester ton FTP en simulant un
accès externe par l'intermediaire de l'adresse fully qualified
Williamhoustra a utilisé son clavier pour écrire :
Salut l'illustre compagnie.
Un mystère ! Je fais, pour partager des trucs et des machins, un petit serveur FTP non anonyme hébergé d'athomique façon. J'ai donc mis le nom de l'URL dans la configuration DNS de mon registrar et il est nécessaire que je le mette aussi dans le DNS du serveur où il arrive. Dans les deux cas c'est donc l'URL suivi de l'adresse IP publique. Bien sûr le routeur-nateur est informé de l'adresse locale où il doit envoyer les petits paquets destinés aux ports 20 et 21.
Tout cela fonctionne parfaitement pour quiconque d'autorisé qui veut s'y connecter sauf... pour moi où il m'est même impossible d'afficher l'arborescence d'un dossier un peu peuplé. Tout se passe comme si il y avait un conflit si l'IP publique demandeuse et l'IP publique émettrice est la même.
En fait mettre l'adresse publique dans mon serveur DNS était une erreur. Ca fonctionnait parfaitement pour des machines tierces mais ça bloquait d'une façon que je ne m'explique toujours pas (limitation des octets) avec ma machine du domaine.
Donc s'il n'y a rien de changé sur le DNS du registrar (où là il faut bien mettre l'adresse publique, c'est évident), il faut juste renseigner, en interne, le serveur FTP dans la machine serveur. C'est nécessaire car sinon un ping n'aboutit pas. Donc créer une étendue "pandemonium-web.net" distincte de celle de l'intranet et y mettre un hôte [A] avec l'adresse locale 192.168.111.24 (celle sur laquelle sont routés les paquets FTP externes).
Donc la machine locale fonctionne sur cette adresse locale pleinement et rien n'est changé pour l'accès des machines extérieures.
De toute façon ta démarche de vouloir tester ton FTP en simulant un accès externe par l'intermediaire de l'adresse fully qualified
at
Il se trouve que at a formulé :
Williamhoustra avait soumis l'idée :
Williamhoustra a utilisé son clavier pour écrire :
Salut l'illustre compagnie.
Un mystère ! Je fais, pour partager des trucs et des machins, un petit serveur FTP non anonyme hébergé d'athomique façon. J'ai donc mis le nom de l'URL dans la configuration DNS de mon registrar et il est nécessaire que je le mette aussi dans le DNS du serveur où il arrive. Dans les deux cas c'est donc l'URL suivi de l'adresse IP publique. Bien sûr le routeur-nateur est informé de l'adresse locale où il doit envoyer les petits paquets destinés aux ports 20 et 21.
Tout cela fonctionne parfaitement pour quiconque d'autorisé qui veut s'y connecter sauf... pour moi où il m'est même impossible d'afficher l'arborescence d'un dossier un peu peuplé. Tout se passe comme si il y avait un conflit si l'IP publique demandeuse et l'IP publique émettrice est la même.
En fait mettre l'adresse publique dans mon serveur DNS était une erreur. Ca fonctionnait parfaitement pour des machines tierces mais ça bloquait d'une façon que je ne m'explique toujours pas (limitation des octets) avec ma machine du domaine.
Donc s'il n'y a rien de changé sur le DNS du registrar (où là il faut bien mettre l'adresse publique, c'est évident), il faut juste renseigner, en interne, le serveur FTP dans la machine serveur. C'est nécessaire car sinon un ping n'aboutit pas. Donc créer une étendue "pandemonium-web.net" distincte de celle de l'intranet et y mettre un hôte [A] avec l'adresse locale 192.168.111.24 (celle sur laquelle sont routés les paquets FTP externes).
Donc la machine locale fonctionne sur cette adresse locale pleinement et rien n'est changé pour l'accès des machines extérieures.
De toute façon ta démarche de vouloir tester ton FTP en simulant un accès externe par l'intermediaire de l'adresse fully qualified
Quel couillon, le message est parti sans prévenir!
En renseignant le fichier hosts de la machine qui héberge le serveur FTP, peut être que tu aboutiras au même résultat (à la place de bidouiller le serveur ftp) ? A tester.
Il se trouve que at a formulé :
Williamhoustra avait soumis l'idée :
Williamhoustra a utilisé son clavier pour écrire :
Salut l'illustre compagnie.
Un mystère ! Je fais, pour partager des trucs et des machins, un petit
serveur FTP non anonyme hébergé d'athomique façon. J'ai donc mis le nom de
l'URL dans la configuration DNS de mon registrar et il est nécessaire que
je le mette aussi dans le DNS du serveur où il arrive. Dans les deux cas
c'est donc l'URL suivi de l'adresse IP publique. Bien sûr le
routeur-nateur est informé de l'adresse locale où il doit envoyer les
petits paquets destinés aux ports 20 et 21.
Tout cela fonctionne parfaitement pour quiconque d'autorisé qui veut s'y
connecter sauf... pour moi où il m'est même impossible d'afficher
l'arborescence d'un dossier un peu peuplé. Tout se passe comme si il y
avait un conflit si l'IP publique demandeuse et l'IP publique émettrice
est la même.
En fait mettre l'adresse publique dans mon serveur DNS était une erreur.
Ca fonctionnait parfaitement pour des machines tierces mais ça bloquait
d'une façon que je ne m'explique toujours pas (limitation des octets) avec
ma machine du domaine.
Donc s'il n'y a rien de changé sur le DNS du registrar (où là il faut
bien mettre l'adresse publique, c'est évident), il faut juste renseigner,
en interne, le serveur FTP dans la machine serveur. C'est nécessaire car
sinon un ping n'aboutit pas. Donc créer une étendue "pandemonium-web.net"
distincte de celle de l'intranet et y mettre un hôte [A] avec l'adresse
locale 192.168.111.24 (celle sur laquelle sont routés les paquets FTP
externes).
Donc la machine locale fonctionne sur cette adresse locale pleinement et
rien n'est changé pour l'accès des machines extérieures.
De toute façon ta démarche de vouloir tester ton FTP en simulant un accès
externe par l'intermediaire de l'adresse fully qualified
Quel couillon, le message est parti sans prévenir!
En renseignant le fichier hosts de la machine qui héberge le serveur
FTP, peut être que tu aboutiras au même résultat (à la place de
bidouiller le serveur ftp) ? A tester.
Williamhoustra a utilisé son clavier pour écrire :
Salut l'illustre compagnie.
Un mystère ! Je fais, pour partager des trucs et des machins, un petit serveur FTP non anonyme hébergé d'athomique façon. J'ai donc mis le nom de l'URL dans la configuration DNS de mon registrar et il est nécessaire que je le mette aussi dans le DNS du serveur où il arrive. Dans les deux cas c'est donc l'URL suivi de l'adresse IP publique. Bien sûr le routeur-nateur est informé de l'adresse locale où il doit envoyer les petits paquets destinés aux ports 20 et 21.
Tout cela fonctionne parfaitement pour quiconque d'autorisé qui veut s'y connecter sauf... pour moi où il m'est même impossible d'afficher l'arborescence d'un dossier un peu peuplé. Tout se passe comme si il y avait un conflit si l'IP publique demandeuse et l'IP publique émettrice est la même.
En fait mettre l'adresse publique dans mon serveur DNS était une erreur. Ca fonctionnait parfaitement pour des machines tierces mais ça bloquait d'une façon que je ne m'explique toujours pas (limitation des octets) avec ma machine du domaine.
Donc s'il n'y a rien de changé sur le DNS du registrar (où là il faut bien mettre l'adresse publique, c'est évident), il faut juste renseigner, en interne, le serveur FTP dans la machine serveur. C'est nécessaire car sinon un ping n'aboutit pas. Donc créer une étendue "pandemonium-web.net" distincte de celle de l'intranet et y mettre un hôte [A] avec l'adresse locale 192.168.111.24 (celle sur laquelle sont routés les paquets FTP externes).
Donc la machine locale fonctionne sur cette adresse locale pleinement et rien n'est changé pour l'accès des machines extérieures.
De toute façon ta démarche de vouloir tester ton FTP en simulant un accès externe par l'intermediaire de l'adresse fully qualified
Quel couillon, le message est parti sans prévenir!
En renseignant le fichier hosts de la machine qui héberge le serveur FTP, peut être que tu aboutiras au même résultat (à la place de bidouiller le serveur ftp) ? A tester.
