Problem mit Debian 12.5 ISCSI-Client ("Initiator")

[jmar83]

Hallo zusammen

In der Daten /etc/iscsi/initiatorname.iscsi steht NUR folgendes

Code: Alles auswählen

InitiatorName=iqn.2000-01.com.synology:synology.Target-11.8b2036156ff

Allerdings:

Code: Alles auswählen

root@debian-btc-node:~# systemctl status open-iscsi.service
× open-iscsi.service - Login to default iSCSI targets
     Loaded: loaded (/lib/systemd/system/open-iscsi.service; enabled; preset: enabled)
     Active: failed (Result: exit-code) since Mon 2024-03-04 17:31:42 CET; 13s ago
       Docs: man:iscsiadm(8)
             man:iscsid(8)
    Process: 5968 ExecStart=/sbin/iscsiadm -m node --loginall=automatic (code=exited, status=19)
   Main PID: 5968 (code=exited, status=19)
        CPU: 7ms

Mär 04 17:31:42 debian-btc-node iscsiadm[5968]: iscsiadm: Could not login to [iface: default, target: iqn.2000-01.com.synology:synology.Target-1.8b2036156ff, portal: 192.168.1.132,3260].
Mär 04 17:31:42 debian-btc-node iscsiadm[5968]: iscsiadm: initiator reported error (19 - encountered non-retryable iSCSI login failure)
Mär 04 17:31:42 debian-btc-node iscsiadm[5968]: iscsiadm: Could not login to [iface: default, target: iqn.2000-01.com.synology:synology.Target-11.8b2036156ff, portal: 192.168.1.132,3260].
Mär 04 17:31:42 debian-btc-node iscsiadm[5968]: iscsiadm: initiator reported error (24 - iSCSI login failed due to authorization failure)
Mär 04 17:31:42 debian-btc-node iscsiadm[5968]: iscsiadm: Could not log into all portals
Mär 04 17:31:42 debian-btc-node iscsiadm[5968]: Logging in to [iface: default, target: iqn.2000-01.com.synology:synology.Target-1.8b2036156ff, portal: 192.168.1.132,3260]
Mär 04 17:31:42 debian-btc-node iscsiadm[5968]: Logging in to [iface: default, target: iqn.2000-01.com.synology:synology.Target-11.8b2036156ff, portal: 192.168.1.132,3260]
Mär 04 17:31:42 debian-btc-node systemd[1]: open-iscsi.service: Main process exited, code=exited, status=19/n/a
Mär 04 17:31:42 debian-btc-node systemd[1]: open-iscsi.service: Failed with result 'exit-code'.
Mär 04 17:31:42 debian-btc-node systemd[1]: Failed to start open-iscsi.service - Login to default iSCSI targets.

(Wie man sieht, geht der Daemon auch auf "Target-1", statt nur auf das definierte "Target-11" - was mE keinen Sinn ergibt. Ist aber ein anderes Thema... Irgendwie geschieht da ein Discovery - aber ich finde keine Anleitungen im Internet wenn mehrere ISCSI-Targets mit untersch. Logins vorhanden sind. (Wäre ein Synology NAS)
)



<iSCSI login failed due to authorization failure> - dies obwohl ich das CHAP-Login in der entsprechenden konfig-Datei richtig eingetragen habe
1. Kennwort genereator nur Zahlen und Buchstaben, Länge 16
2. Copy/paste ins NAS-WebGUI
3. Copyy/paste in die Datei /etc/iscsi/iscsid.conf



Unter Windows geht alles - untersch. Targets mit untersch. Logins - liegt also nicht am ISCSI-Server/Target...


Weiss da evtl. jemand was dazu? Besten Dank für die Feedback

[jmar83]

NAS-GUI:

[jmar83]

Das andere Target - das mit einem anderen System verbunden ist und zu dem ich in Debian 12.5 NICHT verbinden will (es aber trotzdem versucht wird durch den Initiator-Daemon obwohl ganz klar NUR das andere Target [Post oben] in der ensprechenden Konfig-Datei hardcodiert drin ist)

[jmar83]

Das Zeugs raubt einem echt den letzten Tropfen Blut..

[jmar83]

Evtl. ein Bug?

https://bugzilla.proxmox.com/show_bug.cgi?id=5173

[jmar83]

Andernfalls könnte man noch versuchen, das von mir für den Einsatz geplante ISCSI-target #2 (.11) auf den anderen Ethernet-Port zu mappen und das dann über den anderen Ethernet-Port des VirtualBox-Servers (Host Win10 x64 pro) einzusetzen... sprich ne 2. Ethernet-Bridge unter VirtualBox einzurichten...



Wäre aber ne übelste Basel-Lösung, dann kaufe ich mir besser ein zweites NAS und platziere das neben dem aktuellen Nas auch im 192.168.1.x/24-Subnetz...

[jmar83]

Werde es jetzt mal mit dem backports-Kernel versuchen: linux-image-6.5.0-0.deb12.4-amd64

[jmar83]

Ne, auch mit dem backports-Kernel selbiges Problem beim .11-Target:

Mär 04 18:28:21 debian-btc-node iscsiadm[720]: iscsiadm: Could not login to [iface: default, target: iqn.2000-01.com.synology:synology.Target-1.8b2036156ff, portal: 192.168.1.132,3260].
Mär 04 18:28:21 debian-btc-node iscsiadm[720]: iscsiadm: initiator reported error (19 - encountered non-retryable iSCSI login failure)
Mär 04 18:28:21 debian-btc-node iscsiadm[720]: iscsiadm: Could not login to [iface: default, target: iqn.2000-01.com.synology:synology.Target-11.8b2036156ff, portal: 192.168.1.132,3260].
Mär 04 18:28:21 debian-btc-node iscsiadm[720]: iscsiadm: initiator reported error (24 - iSCSI login failed due to authorization failure)


(das .1-Target ist immerhin klar, dort ist das Login tatsächlich nicht das richtige)

[jmar83]

Selbiges Problem?
viewtopic.php?t=180918

[maddeb]

Hast du eine Ahnung, was die Implementierung auf der NAS ist? Ich habe in den letzten Monaten irgendwann folgende Beobachtung gemacht, noch auf Debian 11:

* open-iscsi auf dem Client
* tgt auf dem Server (Debian-Paket tgt, Projekthomepage is http://stgt.sourceforge.net/, "tgt" scheint noch was anderes zu sein

und es stellte sich heraus, dass tgt kein SHA256 konnte. Mit MD5 ging Authentifizerung, in beide Richtungen.

Bei einem zweiten Blick stellen sich mir noch mehr Fragen:

In der Daten /etc/iscsi/initiatorname.iscsi steht NUR folgendes:

InitiatorName=iqn.2000-01.com.synology:synology.Target-11.8b2036156ff

Der Initiatorname hat mit dem Targetname nicht so viel zu tun, es ist ein Name fur die Clientseite. Kann man fuer ACLs benutzen, ansonsten wuesste ich nicht, wozu der genaue WErt wichtig ist, abgesehen davon, das verschiedene Clients unterschiedliche Namen haben sollten. Und auch einen anderen Namen als das Target. Mir scheint, du hast da den Namen des Targets als den Namen es Initiator eingetragen.

<iSCSI login failed due to authorization failure> - dies obwohl ich das CHAP-Login in der entsprechenden konfig-Datei richtig eingetragen habe

Was ist die "entsprechende" Datei? Bei mir hat jedes einzelne Target eine einzelne Datei irgendwo unter /etc/iscsi/nodes, unter unter /etc/iscsi/send_targets und /etc/iscsi/static liegen Symlinks darauf, je nach Konfigurationstyp. Und fuer jedes Target gibt es separate Authentifizierung.

Oder verstehe ich das Setup falsch? Ich verstehe jedenfalls noch nicht so recht, was du da gemacht hast, und was am Ende wo genau steht. Wenn du GUIs benutzt, dann ist es schwierig nachzuvollziehen, was da genau passiert, deswegen predige ich immer Kommandozeile. DAnn kannst du die genauen Kommandos posten, und deren Ausgabe. Du kannst ja mal sehen, was du in den von mir zuvor genannten Dateien stehen hast, oder ob die ueberhaupt existieren. Und ich meine, du kommst auch per SSH auf eine Synology rauf, um dort die Configs zu finden.

[jmar83]

Hallo maddeb

Besten Dank für deine Antwort.

Auf der NAS läuft unter am Ende ein Linux, in diesem Fall müsste man serverseitig wohl mit "tgt" rechnen: https://www.synology.com/de-de/dsm/7.1/ ... e_spec/dsm

Wenn es sein muss, kann man sich dort auch per root anmelden, habe das mal auf einem anderen (älteren) Gerät von Synology in einer Firma, wo ich mal gearbeitet habe, gemacht.

Aha, dann muss man unter /etc/iscsi/initiatorname.iscsi nicht den Target-Name einfügen? (Na ja, der Dateiname spricht wohl nicht gerade dafür).

Wobei in dieser Anleitung hier "change to the same IQN you set on the iSCSI target server" steht:
https://www.server-world.info/en/note?o ... =iscsi&f=3

Deshalb dachte ich, ich müsse dort das einfügen, was beim Screenshot markiert ist.

<Was ist die "entsprechende" Datei?>


-> /etc/iscsi/iscsid.conf

https://www.server-world.info/en/note?o ... =iscsi&f=3

Das ist soweit klar, was drinstehen soll - dass CHAP-Auth verwendet werden soll wie auch Benutzername + Kennwort (wie auch node.startup = automatic, heisst wohl soll automatisch verbinden beim OS-Start?)

Bis jetzt habe ich immer alles versucht per nano unter der Konsole zu konfigurieren.

Grundsätzlich müsste man ja folgende Sachen eintragen:

- Benutzername (klar!)
- Kennwort (klar!)
- IP-Adresse (unklar)
- ISCSI-Target-Name (unklar)

(Bei Windows ist es so, dass man zuerst die IP einträgt, dann sieht man die versch. Targets welche man einzeln per CHAP authentifizieren kann... beim Start verbindet dann alles automatisch. Unter Linux müsste das in etwa ähnlich sein, dort habe ich aber kein GUI um das Target anzuklicken - demzufolge müsste es in eine konfig-Datei rein)

[jmar83]

Es bestehen von meiner Seite her generell folgende 2 Fragen:

- Wie kann ich veranlassen, dass der "iscsid" nur auf Target X verbindet - in welcher Datei muss ich das konfigurieren?
- Warum klappt das Login beim Target "iqn.2000-01.com.synology:synology.Target-11.8b2036156ff" nicht obwohl Benutzername + Kennwort korrekt sind?

Beim Target "Target-1", also "iqn.2000-01.com.synology:synology.Target-1.8b2036156ff", ist klar weshalb das Login nicht klappt - dieser Target hat ein anderes Login, deshalb die Meldung "19 - encountered non-retryable iSCSI login failure"... beim "Target-11" aber die Meldung "24 - iSCSI login failed due to authorization failure" - obwohl Benutzer + Kennwort korrekt

[jmar83]

Habe nun ssh im Web-GUI vom NAS aktiviert, dann mich mit demselben User eingeloggt wie das Web-GUI verwendet, dann "sudo -i" eingegeben u. nochmal das Web-GUI-USer-Kennwort:
https://kb.synology.com/de-de/DSM/tutor ... SSH_Telnet

Anscheinend läuft da doch kein "tgt" als ISCSI-Target-Dienst:

[jmar83]

Zum NAS-Linux kann ich nur das herausfinden - alle andere Befehle und Dateien (/etc/issue, /proc/version wie unter https://www.cyberciti.biz/faq/how-to-ch ... mand-line/ beschrieben) existieren anscheinend nicht:

root@synology:~# cat /proc/version
Linux version 4.4.180+ (root@build3) (gcc version 8.5.0 (GCC) ) #42962 SMP Mon May 29 14:38:23 CST 2023

[maddeb]

Hallo Jan,

fuer mich war es auch ein anstrengender Weg zu verstehen, was die einzelnen Komponenten so tun. Die Doku finde ich so mittel, die Beispiele, die man s findet, sind sehr einfach gehalten, und ich habe irgendwann angefangen, mit Wireshark mitzulesen, was passiert, und das gleichzeitig im Quellcode mitzuverfolgen. Ich finde es immer noch schwierig, den Zustand deines Systems nachzuvollziehen. Mein Vorschlag:

* resette die Config auf der Clientseite komplett.
* Fass initiatorname.conf und iscsid.conf nicht weiter an. Und schon gar nicht sollte Initiatorname == Targetname sein.
* Falls nicht in der Vergangenheit erfolgreich, stell Authentifizierung auf der Serverseite erstmal ab, in beide Richtungen. Ich nehme an, die gehen nicht (direkt) ueber das Internet?
*

Code: Alles auswählen

iscsiadm -m discoverydb -t send_targets --discover <server>

(ist jetzt frei aus dem Kopf, schau im Zweifel in der Doku nach), das sollte fuer jedes Target eine einzelne Datei erzeugen. In diesen Dateien kannst du dann per Hand die Authdaten einstellen und auch, ob die Verbindung automatisch aufgebaut werden soll.
* wenn ein Schritt funktioniert, dann teste die naechste Aenderung. Bei Authemtifizierung ist der Texteditor sowieso der einzige Weg, die einzupflegen, der fuer mich funktionert hat. Es gibt noch die Meoglichkeit, auf Config ganz zu verzichten und mit

Code: Alles auswählen

iscsistart

die Verbindung aufzubauen, ABER das handelt dir Session ein, die du nur beendet kriegst, wenn du in iscsid.conf

Code: Alles auswählen

iscsid.safe_logout = No

stehen hast. Nicht optimal, andernfalls, wenn du die eine Session beenden willst, kriegst su sonst die Meldung, dass sie nicht existiere. Zumnindest unter Debian 11. Wenn du bei iscsiadm bleibst, solltest du diese Art Problem nicht haben, ich habe das nur der Vollstaendigkeit halber erwaehnt.
* Es gibt eine moegliche Falle: das Passwort fuer einen User gilt fuer das gesamte Portal. Wenn du den gleichen User auf unterschiedlichen Targets benutzt, aber mit unterschiedlichen Passworten, dann wird letztendlich nur eines gueltig.

Zu systemd kann ich nicht viel sagen, aber wenn du rausfinden willst, was da auf der NAS laeuft, dann gibt die Standardwerkzeuge, z.B.

Code: Alles auswählen

netstat -tuplen

, das sollte den Prozess anzeigen, der auf Port 3260 horcht, das gibt dir meistens schon einen Dateinamen, aber definitiv eine PID, und damit findet man under /proc schon mehr.

[jmar83]

<Falls nicht in der Vergangenheit erfolgreich, stell Authentifizierung auf der Serverseite erstmal ab, in beide Richtungen. Ich nehme an, die gehen nicht (direkt) ueber das Internet?>

Ja, ich denke auch dass es dann gehen sollte - und nein, ist ne lokale Sache, selbiges Subnetz.

Vielen Dank, werde mal schauen!!