6 réponses à ce sujet

[eric13500]

Bonjour à toutes et tous !

Pour aller droit au but :

Sur un QNAP TS219P+ j'ai configuré une cible iSCI et un LUN associé.

Sur le routeur côté serveur, j'ai ouvert le port 3260 en TCP/UDP

Sur un client distant Windows 7, j'ai lancé une recherche de portail dans l'initiateur iSCI.
Le portail a bien été trouvé, et le LUN cible est bien présent dans l'onglet "Cibles"; pourtant, lorsque je sélectionne la cible que je clique sur "Connexion", l'initiateur mouline 5 minutes et me répond irrémédiablement "Echec lors de la connexion".

J'ai essayé avec et sans identification CHAP...

Je remercie par avance quiconque saura m'apporter une réponse.

Dans l'attente, bien cordialement,
Eric.

[father_mande]

Bonjour,

eric13500, le 03 septembre 2011 - 01:17 , dit :

Bonjour à toutes et tous !

Pour aller droit au but :

Sur un QNAP TS219P+ j'ai configuré une cible iSCI et un LUN associé.

Sur le routeur côté serveur, j'ai ouvert le port 3260 en TCP/UDP

Sur un client distant Windows 7, j'ai lancé une recherche de portail dans l'initiateur iSCI.
Le portail a bien été trouvé, et le LUN cible est bien présent dans l'onglet "Cibles"; pourtant, lorsque je sélectionne la cible que je clique sur "Connexion", l'initiateur mouline 5 minutes et me répond irrémédiablement "Echec lors de la connexion".

J'ai essayé avec et sans identification CHAP...

Je remercie par avance quiconque saura m'apporter une réponse.

Dans l'attente, bien cordialement,
Eric.

Iscsi n'a pas été conçu pour un usage depuis Internet ou via un routeur ...
C'est un outil qui vise le réseau (local) Gigabit, 10GbE et même plutôt les liens fibres ....
donc les timers sont adaptés à ces types de vitesse .... puisque c'est un gestion de type disque physique ... pas disque réseau, comme un partage NFS ou Samba

La phase de connexion se passe ...
1 obtenir une liste de cibles (lent donc réponse obtenu facilement)
2 établir un lien (et un login) lent
3 début des échanges "comme pour un disque dur", donc demande de lecture avec timer, reprise, réception (parfois) reprise ... tout se passe au niveau "bloc" du disque ; ce qui est transféré c'est des ordre de lecture / écriture de type SCSI et les réponses ou blocs a écrire sont transmis comme des blocs "physiques" d'un disque ...

J'ai déjà pu avoir un (piétre) résultat (inutilisable) "normalement" en maitrisant le client "Open Iscsi" et ses "timers" et le target_iscsi sous Linux. Ce qui n'est pas le cas avec QNAP target et encore moins avec un client Windows ... MAIS c'était une plateforme et pas réellement utilisable ... I_Scsi N'A PAS ÉTÉ CONSTRUIT pour ce type d'usage ...

Quand je veux avoir accès a mes disques I_Scsi du QNAP depuis le réseau Internet (et donc n'ai pas de connexion locale, car comme c'est un disque attaché a UN client, il n'y a pas de partage possible (si ce n'est au niveau d'un applicatif) )
Je monte localement la cible I_Scsi en utilisant l'interface Web des disques Virtuels (adresse I.P. 127.0.0.1 (loopback)), puis je crée une ressource partagée (Samba, NFS, WebDav, FTP, WebFilemanager etc. etc. ) qui me permet d'accéder au contenu de ma cible I_Scsi ... et je n'oublie pas de fermer la connexion AVANT de me reconnecter en local ...

Philippe.
NB il y a peut-être (surement) plus simple ... mais là je suis à la limite des mes compétences

[eric13500]

father_mande, le 03 septembre 2011 - 09:06 , dit :

Bonjour,


Iscsi n'a pas été conçu pour un usage depuis Internet ou via un routeur ...
C'est un outil qui vise le réseau (local) Gigabit, 10GbE et même plutôt les liens fibres ....
donc les timers sont adaptés à ces types de vitesse .... puisque c'est un gestion de type disque physique ... pas disque réseau, comme un partage NFS ou Samba

La phase de connexion se passe ...
1 obtenir une liste de cibles (lent donc réponse obtenu facilement)
2 établir un lien (et un login) lent
3 début des échanges "comme pour un disque dur", donc demande de lecture avec timer, reprise, réception (parfois) reprise ... tout se passe au niveau "bloc" du disque ; ce qui est transféré c'est des ordre de lecture / écriture de type SCSI et les réponses ou blocs a écrire sont transmis comme des blocs "physiques" d'un disque ...

J'ai déjà pu avoir un (piétre) résultat (inutilisable) "normalement" en maitrisant le client "Open Iscsi" et ses "timers" et le target_iscsi sous Linux. Ce qui n'est pas le cas avec QNAP target et encore moins avec un client Windows ... MAIS c'était une plateforme et pas réellement utilisable ... I_Scsi N'A PAS ÉTÉ CONSTRUIT pour ce type d'usage ...

Quand je veux avoir accès a mes disques I_Scsi du QNAP depuis le réseau Internet (et donc n'ai pas de connexion locale, car comme c'est un disque attaché a UN client, il n'y a pas de partage possible (si ce n'est au niveau d'un applicatif) )
Je monte localement la cible I_Scsi en utilisant l'interface Web des disques Virtuels (adresse I.P. 127.0.0.1 (loopback)), puis je crée une ressource partagée (Samba, NFS, WebDav, FTP, WebFilemanager etc. etc. ) qui me permet d'accéder au contenu de ma cible I_Scsi ... et je n'oublie pas de fermer la connexion AVANT de me reconnecter en local ...

Philippe.
NB il y a peut-être (surement) plus simple ... mais là je suis à la limite des mes compétences

Bonjour Philippe, et merci de cette réponse rapide et précise.
J'avoue ne pas avoir très bien compris la méthode que tu proposes à la fin, mais j'ai en revanche très bien compris qu'iSCSI n'était pas adapté à mes besoins.
En fait, je cherchais à contourner l'impossibilité sur W7 d'accéder à un dossier via WebDav...
Je sais qu'il existe des clients (comme Bitkinex) qui peuvent le faire, mais je voulais vraiment avoir une intégration de l'emplacement distant dans l'arborescence de Windows...
J'espère qu'un correctif finira bientôt par être proposé, parce qu'il me semble que le VPN est une fonction qu'on est en droit d'attendre lorsqu'on s'équipe d'un serveur...
Alors je sais, je mets en vrac plusieurs protocoles, mais l'idée reste d'accéder à une ressource distante depuis une plateforme Windows, la plus utilisée par mes clients, qui eux ne sont pas de la partie et qui préfèreront toujours avoir une intégration que de devoir utiliser un logiciel tiers...

Si tu as une solution dont je n'ai pas encore entendu parler, je te serai infiniment reconnaissant de m'en faire part.

Quoi qu'il en soit, je te remercie encore d'avoir pris le temps de m'instruire sur le sujet.

Bien cordialement,
Eric.

[father_mande]

Bonjour,

eric13500, le 03 septembre 2011 - 09:57 , dit :

Bonjour Philippe, et merci de cette réponse rapide et précise.
J'avoue ne pas avoir très bien compris la méthode que tu proposes à la fin, mais j'ai en revanche très bien compris qu'iSCSI n'était pas adapté à mes besoins.
En fait, je cherchais à contourner l'impossibilité sur W7 d'accéder à un dossier via WebDav...
Je sais qu'il existe des clients (comme Bitkinex) qui peuvent le faire, mais je voulais vraiment avoir une intégration de l'emplacement distant dans l'arborescence de Windows...
J'espère qu'un correctif finira bientôt par être proposé, parce qu'il me semble que le VPN est une fonction qu'on est en droit d'attendre lorsqu'on s'équipe d'un serveur...
Alors je sais, je mets en vrac plusieurs protocoles, mais l'idée reste d'accéder à une ressource distante depuis une plateforme Windows, la plus utilisée par mes clients, qui eux ne sont pas de la partie et qui préfèreront toujours avoir une intégration que de devoir utiliser un logiciel tiers...

Si tu as une solution dont je n'ai pas encore entendu parler, je te serai infiniment reconnaissant de m'en faire part.

Quoi qu'il en soit, je te remercie encore d'avoir pris le temps de m'instruire sur le sujet.

Bien cordialement,
Eric.

Bon ... j'ai encore été un peu "bref" dans mes explications ...

Une cible iscsi peut très bien être utilisé en local, le QNAP étant serveur et client c'est dans le Web Admin, la fonction gestion de disque / disque virtuel qui représente le client iscsi
Il suffit de prendre comme adresse I.P. du serveur 127.0.0.1 (localhost ou loopback), vous y verrez vos cibles iscsi et vous pourrez les connecter ... une fois ces disques virtuels connectés, rien ne vous empêche de les utiliser comme une ressource partagée et donc de lire leur contenu (et écrire)

Les clients comme Bitkinnex ... sont un moindre mal ... mais essayez aussi avec le firmware 3.5, la compatibilité (malgré Microsoft) a été améliorée.

Sinon, vous pouvez aussi (autre solution) utiliser une connexion VPN, bon aujourd’hui il n'y a que OpenVPN (mais c'est bien plus sur que le PPTP de Microsoft) et pas plus compliqué si vous voulez encoder vos données, car IPsec associé a PPTP n'est pas aussi implicite que OpenVPN ... OpenVPN vous garantissant une compatibilité avec Mac, Linux, IOS et Android pour ne citer que ceux là ... beaucoup d'utilisateur pense qu'il ont une sécurité en utilisant PPTP si simple a mettre en oeuvre sur Windows ... et bien ils se mettent le doigt dans l"oiel et jusqu'au cerveau ...

Le QPKG OpenVPN est disponible, même si les annonces QNAP (3.6 a priori) vont le rendre obsolète ...

Philippe.

[eric13500]

Encore merci pour cette nouvelle réponse express !

father_mande, le 03 septembre 2011 - 14:06 , dit :

Bonjour,
Bon ... j'ai encore été un peu "bref" dans mes explications ...

Une cible iscsi peut très bien être utilisé en local, le QNAP étant serveur et client c'est dans le Web Admin, la fonction gestion de disque / disque virtuel qui représente le client iscsi
Il suffit de prendre comme adresse I.P. du serveur 127.0.0.1 (localhost ou loopback), vous y verrez vos cibles iscsi et vous pourrez les connecter ... une fois ces disques virtuels connectés, rien ne vous empêche de les utiliser comme une ressource partagée et donc de lire leur contenu (et écrire)

Là, je comprends beaucoup mieux le principe et le fonctionnement ! ...
mais je ne vois pas l'utilité de la manip Créer une cible iSCSI, lui associer un LUN, y mapper un lecteur virtuel... qui sera vu à distance comme un dossier partagé
Quel en est l'intérêt ? Si on peut accéder à celui-ci, on peut accéder aux autres, et on revient au VPN (à moins que je n'ai encore loupé un épisode ).

father_mande dit :

Les clients comme Bitkinnex ... sont un moindre mal ... mais essayez aussi avec le firmware 3.5, la compatibilité (malgré Microsoft) a été améliorée.

Ca signifie qu'on peut peut-être accéder au dossier via WebDav sur une plateforme Windows

father_mande dit :

Sinon, vous pouvez aussi (autre solution) utiliser une connexion VPN, bon aujourd’hui il n'y a que OpenVPN (mais c'est bien plus sur que le PPTP de Microsoft) et pas plus compliqué si vous voulez encoder vos données, car IPsec associé a PPTP n'est pas aussi implicite que OpenVPN ... OpenVPN vous garantissant une compatibilité avec Mac, Linux, IOS et Android pour ne citer que ceux là ... beaucoup d'utilisateur pense qu'il ont une sécurité en utilisant PPTP si simple a mettre en oeuvre sur Windows ... et bien ils se mettent le doigt dans l"oiel et jusqu'au cerveau ...

Le QPKG OpenVPN est disponible, même si les annonces QNAP (3.6 a priori) vont le rendre obsolète ...

Philippe.

Je m'étais penché sur OpenVPN et le QPKG correspondant, mais la solution m'avait semblée difficile à mettre en oeuvre, surtout si on considère que j'ai des clients qui veulent se connecter de chez eux au serveur de leur entreprise (comme de nombreux utilisateurs VPN).

Obsolète dans quel sens ? que le QPKG ne fonctionnera plus, ou qu'il deviendra inutile ?

Bien cordialement,
Eric.

[father_mande]

Bonjour,

eric13500, le 03 septembre 2011 - 14:23 , dit :

Encore merci pour cette nouvelle réponse express !


Là, je comprends beaucoup mieux le principe et le fonctionnement ! ...
mais je ne vois pas l'utilité de la manip Créer une cible iSCSI, lui associer un LUN, y mapper un lecteur virtuel... qui sera vu à distance comme un dossier partagé
Quel en est l'intérêt ? Si on peut accéder à celui-ci, on peut accéder aux autres, et on revient au VPN (à moins que je n'ai encore loupé un épisode ).


Ca signifie qu'on peut peut-être accéder au dossier via WebDav sur une plateforme Windows


Je m'étais penché sur OpenVPN et le QPKG correspondant, mais la solution m'avait semblée difficile à mettre en oeuvre, surtout si on considère que j'ai des clients qui veulent se connecter de chez eux au serveur de leur entreprise (comme de nombreux utilisateurs VPN).

Obsolète dans quel sens ? que le QPKG ne fonctionnera plus, ou qu'il deviendra inutile ?

Bien cordialement,
Eric.

1 ) une cible iscsi est un gros fichier RAW dynamique du point de vue du QNAP
... lorsque vous l'utilisez depuis un PC client (Windows) ce PC voit le fichier comme une unité de disque formaté en (ce qu'il veut) et s'en sert comme un disque "normal"
... quand l'utilisateur n'est plus en ligne, il ne reste qu'un gros fichier sur le QNAP qui est illisible ... que vous utilisiez VPN, Samba, Webdav ... vous ne verriez qu'un gros tas d'octet.
... utilisez le client iscsi local au QNAP donne au QNAP une visibilité sur le contenu de ce gros tas d'octets ... fichiers, répertoires, etc.
... ces données maintenant accessible peuvent être associé à un utilisateur, qui va accéder à ces données via un des outils du QNAP ...

2 ) a priori la 3.5 devrait améliorer les choses, mais je n'ai pas testé ... mes utilisateurs une fois passées les quelques minutes d'apprentissage de Bitkinex ... ont pris l'habitude ... mais l'amélioration de la compatibilité a été annoncé par QNAP ... est-ce que cela fonctionne ???

3 ) OpenVPN comme toutes autres solutions sécurisées est a mettre en œuvre suivant un protocole de gestion de clefs ... le QPKG essaye (en tenant compte des restrictions du au QNAP) de limiter l'ensemble des opérations a des modifications dans 1 seul fichier ... et de plus génère pour chaque client un répertoire qui contient TOUT ce dont a besoin un client ... désolé je n'ai pas trouvé plus simple (je ne suis pas assez bon pour faire une interface Web .... ) de plus ceci n'enlève pas la complexité du problème.

Le QPKG va devenir obsolète car QNAP a annoncé l'intégration de OpenVPN et de PPTP (le protocole de tunnel de Microsoft) dans une des versions à venir (la 3.6), donc OUI il deviendra inutile ... mais la compréhension du problème restera ...
entre autre la confusion de beaucoup d'utilisateur qui pensent que le PPTP de Microsoft est sécurisé ce qui est faut, le tunnel n'est pas encrypté ... donc un sniffeur ... et tout est visible, si on veut un bon niveau de sécurité il faut ajouter IPsec ... et là on retombe dans la gestion des clefs ... et mon avis (donc sans valeur) est qu'il est plus facile de maitriser le tout avec OpenVPN qu'avec un ensemble PPTP IPsec dont on a PAS la visibilité interne (pas le code) .... mais bon, chacun fait ce qu'il lui plait.

Philippe.

[eric13500]

father_mande, le 03 septembre 2011 - 18:21 , dit :

Bonjour,


1 ) une cible iscsi est un gros fichier RAW dynamique du point de vue du QNAP
... lorsque vous l'utilisez depuis un PC client (Windows) ce PC voit le fichier comme une unité de disque formaté en (ce qu'il veut) et s'en sert comme un disque "normal"
... quand l'utilisateur n'est plus en ligne, il ne reste qu'un gros fichier sur le QNAP qui est illisible ... que vous utilisiez VPN, Samba, Webdav ... vous ne verriez qu'un gros tas d'octet.
... utilisez le client iscsi local au QNAP donne au QNAP une visibilité sur le contenu de ce gros tas d'octets ... fichiers, répertoires, etc.
... ces données maintenant accessible peuvent être associé à un utilisateur, qui va accéder à ces données via un des outils du QNAP ...

2 ) a priori la 3.5 devrait améliorer les choses, mais je n'ai pas testé ... mes utilisateurs une fois passées les quelques minutes d'apprentissage de Bitkinex ... ont pris l'habitude ... mais l'amélioration de la compatibilité a été annoncé par QNAP ... est-ce que cela fonctionne ???

3 ) OpenVPN comme toutes autres solutions sécurisées est a mettre en œuvre suivant un protocole de gestion de clefs ... le QPKG essaye (en tenant compte des restrictions du au QNAP) de limiter l'ensemble des opérations a des modifications dans 1 seul fichier ... et de plus génère pour chaque client un répertoire qui contient TOUT ce dont a besoin un client ... désolé je n'ai pas trouvé plus simple (je ne suis pas assez bon pour faire une interface Web .... ) de plus ceci n'enlève pas la complexité du problème.

Le QPKG va devenir obsolète car QNAP a annoncé l'intégration de OpenVPN et de PPTP (le protocole de tunnel de Microsoft) dans une des versions à venir (la 3.6), donc OUI il deviendra inutile ... mais la compréhension du problème restera ...
entre autre la confusion de beaucoup d'utilisateur qui pensent que le PPTP de Microsoft est sécurisé ce qui est faut, le tunnel n'est pas encrypté ... donc un sniffeur ... et tout est visible, si on veut un bon niveau de sécurité il faut ajouter IPsec ... et là on retombe dans la gestion des clefs ... et mon avis (donc sans valeur) est qu'il est plus facile de maitriser le tout avec OpenVPN qu'avec un ensemble PPTP IPsec dont on a PAS la visibilité interne (pas le code) .... mais bon, chacun fait ce qu'il lui plait.

Philippe.

Bonjour Philippe, et encore merci pour votre patience et disponibilité.

Cet échange m'aura vraiment permis de mieux comprendre ce qu'est une cible iSCSI, et je suis certain qu'il éclairera plus d'un visiteur.

La seule question qui me reste, pour clôturer et en espérant ne pas abuser, est que je ne comprends pas vraiment l'intérêt dune cible par rapport à un dossier partagé... ça reste à mes yeux novices deux unités de stockage, avec cette impression que la seule différence sur le client est le niveau hiérarchique dans son arborescence... à moins effectivement qu'on ait besoin à la fois d'unités FAT et NTFS... est-ce là la seule utilité de l'iSCSI, ou quelque chose m'échappe-t-il encore ?
En gros, quelles sont les différence majeures entre les deux et dans quel cas opter de façon tranchée pour l'un plutôt que pour l'autre (je parle cette fois pour un client local, ayant bien noté qu'iSCSI est impropre à l'utilisation distante) ?

Bien cordialement,
Eric.