Generell sollte man nur TLS mit Zertifikat einrichten. Spätestens mit eAU und eRp braucht man es wenn man sinnvoll arbeiten will. Die Komfortsignatur geht nicht ohne TLS mit Zertifikat.
Zitat von FS007 im Beitrag #17Mit der Kocobox funktioniert TLS mit Zertifikat eh nicht.
Bei uns funktioniert die Kombination gut, wenn es um die Verwendung mit dem Konnektor geht.
Dass Anwendungen mit Zertifikat + TLS nicht wie erwartet funktionieren habe ich auch erfahren und finde es schade. Hier hätten die Hersteller von vornherein entsprechende Anpassungen vornehmen müssen. Außerdem sollte es gute Handbücher/Dokumentationen/Anleitungen geben, die einen durch die Konfiguration der Produkte leiten. Wenn dies vernünftig geregelt worden wäre, hätten wir jetzt nicht diese Diskussion.
Bitte auf die Gültigkeistdauer der Zertifikate achten!
Ich konne nach dem 17.6.2022 keine Nachrichten via KIM mehr versenden.
Hat mich einigie Stunden Zeit gekostet bis ich sah,daß das Zertifikat in der Kocobos abgelaufen war und deshalb der Zugangzum Konnektor blockiert wurde.
Bitte nicht vergessen : Nach einem Jahr ist das Zertifikat abgelaufen und es muß ein neues angelegt werden .Abgelaufende Zertifikate löschen.
1 Mitglied findet das Top!
1 Mitglied hat sich bedankt!
ich habe anscheinend hat selbe Problem, wenn ich versuche eine eRezept auszustellen, dann kommt noch kurzer Zeit "Erstellung fehlgeschlagen"
In den Sicherheitsprotokollen der Kocobox kann ich zu dem Zeitpunkt folgende Einträge sehen.
BlockedPacket=Von 100.88.47.64:46618 nach 100.97.135.49:3128 mit Protokoll TCP über Adapter lan.; Aktion=Drop BlockedPacket=Von 192.168.xx.xxx:49389 nach 100.102.29.10:443 mit Protokoll TCP über Adapter lan.; Aktion=Drop BlockedPacket=Von 100.88.47.64:46618 nach 100.97.135.49:3128 mit Protokoll TCP über Adapter lan.; Aktion=Drop
ich glaube nicht, dass dieses mit blocked packets hier überhaupt irgendwas mit dem Problem eRezept zu tun hat:
Es stimmt, dass die Kocobox einen konstanten Traffic an blocked packets hat- und somit werden Sie immer, auch wenn Sie z.B. Erezept starten und in die Kocobox dann in die Logs schauen, zeitgleich was finden, frage ist nur, ob das mit dem Problem "erzept läuft nicht" in irgendeinem Zusammenhang steht. Und ich bezweifele das, weil das von der Logik her auch funktionell vom eRezept Prozessablauf her nicht passt.
Denn der ERezept ist ein Prozess, der nicht separat läuft, sondern den Bestands-VPN nutzt- also wenn ansonsten von Karten einlesen bis KIM alles läuft sollte auch hier kein grundsätzliches Hindernis für eRezept sein.
Zitat von MarcusD im Beitrag #20wenn ich versuche eine eRezept auszustellen, dann kommt noch kurzer Zeit "Erstellung fehlgeschlagen"
Ich würde daher eher mal in Richtung AIS/PVS DIenst Problem schauen- Erstellung fehlgeschlagen ist der erste Schritt , also wenn das PVS das eRezept ausfertigt zur Signatur- danach signiere ich- danach erst geht das eREzept via VPN in die VAU der TI und wird danach dann bereitgestellt. Also alles VOR dem eigentlichen TI Prozess.
Wann genau kommt die Fehlermeldung- noch VOR Signatur mit EHBA oder bei Ihnen danach? ich vermute, die Meldung kommt noch davor, richtig?
Kann es somit sein, dass irgendwas im Erstellprozess hakt ganz am Anfang noch ohne dass die nachfolgenden TI Strukturen dran sind: Könnte z.B. was Richtung unvollständige Daten zum Kassenarztstempel sein: Fehlende lebenslange Arztnummer, Adressdaten oder was auch immer unvollständig. Oder fehlende Rechte im PVS/AIS oder sowas?
Wenn also eher somit wenn bei den Diensten des AIS/PVS mal schauen, was da in den Logs steht. Idee wäre auch ggf. mal diese DIenste neu starten, im Besonderen, wenn grad vielleicht Änderungen (andere Ärzte, andere Smartcards ...) gelaufen sein sollten.
Welches PVS/AIS ist es denn bei Ihnen wo es nicht läuft im Moment mit eRezept? Gibt es ggf. andere Praxen mit gleichem PVS- ist das mit eRezept schon gelaufen dort ?
Ich hab eben mal eRezepte rausgeschickt von meinem PVS (Charly/Solutio) aus: Die sind ohne Fehler rausgegangen und inzwischen auch als Rückläufer aus der VAU im Status "bereitgestellt" lt. unserem PVS.
Ich habe mal in der Kocobox versucht zu schauen, wo sich in den Logs da was tut, während man eRezept initiiert- also wenn hätte ich eher was Passendes im Systemprotokoll vom VSDM: füge ich gleich mal als Beispiel bei: Und wenn es somit im Prozess VPN liegen würde würde es dann eher dort bei VSDM Modul in den Logs auftauchen,meine ich.
Sie können ja mal diese Screens von mir mit Ihren Kocologs bei VSDM Modul vergleichen. Und mal im VSDM Fehlerlog schauen, ob da überhaupt was drin ist- wenn nicht, haben Sie vermutlich auch kein Problem auf dieser Ebene.
Unabhängig davon ist interssant, was das eigentlich für blocked packets sind, die da ständig auflaufen.
Zum Trost: bei mir sieht das fast identisch aus, und das obwohl ich keine Probleme mit eREzept habe. Ich habe teilweise sogar die gleichen IP Adressen, habe eben mal verglichen.
z.B. - [[File:security.7z|none|auto]]
Und einige wenige Adressen bei blocked packets sind ja tatsächlich auch vom Praxisnetzwerk intern 192.168.100 ausgehend- das kann ich noch einordnen, wo die herkommen, wenn auch nicht, warum die grad jetzt hier "blocked" werden, aber es scheint funktionell jedenfalls keinen Einfluss zu haben.
z.B.
Zitat von MarcusD im Beitrag #20"BlockedPacket=Von 192.168.xx.xxx:49389 nach 100.102.29.10:443 mit Protokoll TCP über Adapter lan.; Aktion=Drop
Frage ist aber, was die anderen ip Adressen darstellen und woher die kommen- das sind wenn man das bei whois eingibt, sämtlich spezielle Adressbereiche, die jedenfalls bei mir mit den Adressbereichen Praxisnetzwerk intern so rein gar nichts zu tun haben...
Zitat von MarcusD im Beitrag #20BlockedPacket=Von 100.88.47.64:46618 nach 100.97.135.49:3128 mit Protokoll TCP über Adapter lan.; Aktion=Drop (...) BlockedPacket=Von 100.88.47.64:46618 nach 100.97.135.49:3128 mit Protokoll TCP über Adapter lan.; Aktion=Drop
Whois sagt dazu, wenn ich diese Adressen abfrage:
ZitatShared Address Space can only be used in Service Provider networks or on routing equipment that is able to do address translation across router interfaces when addresses are identical on two different interfaces.
Ich weiß zu wenig dazu, um das jetzt genau einordnen zu können fachlich- vielleicht irgendwas Kommunikation zwischen Routern ,vielleicht NAT interne Adressen auf extern - sowas die Richtung, aber richtig erklären kann ich es nicht, wäre aber neugierig dazuzulernen, somit @MLangguth gerne nähere Erklärung dazu bei Gelegenheit mit Danke im Voraus:-)
Junioruser1976
hat folgende Dateien an diesen Beitrag angehängt
danke für den ausführlichen Beitrag. Wir nutzen in der Praxis ebenfalls Solutio Charly mit der Kocobox als Konnektor. Das eRezept hat noch nie funktioniert und sobald ich auf den Button "erstellen" drücke, kommt nach einigen Sekunden "Erstellung fehlgeschlagen".
Im beschriebenen Workflow von Solutio bleibt der Prozess anscheinend hier stehen "→ Das E-Rezept erhält vom E-Rezept-Fachdienst einen Token (Rezeptcode) und wird für die Signierung vorbereitet."
Der Support von Solutio meinte, ich müßte in der Kocobox einen DNS-Resolver hinterlegen damit es funktioniert. (Hinweis: Für die Nutzung des E-Rezeptes muss Ihr Konnektor als DNS-Resolver konfiguriert sein, so dass der E-Rezept Fachdienst in der TI korrekt ermittelt werden kann.)
Jetzt habe den die KocoBox als DNS in der Netzwerkverbindung eingefügt und bekomme auch eine Antwort wenn ich "nslookup erp.zentral.erp.splitdns.ti-dienste.de mache."
Unter VSDM finde ich gar keine Einträge mit Zeitstempel , die auf das eRezept vermuten lassen.
das ist in der Tat spannend, zumal ich mich wundere, warum plötzlich auf der Kocobox noch DNS Resolver was aktiv eingerichtet werden sollen müsste: Also ich hab meine Kacaobox ja diesbezüglich auch nicht aktiv angefassen müssen (habe Version 4.2.22 im Moment/neues Modell schon- aber auch mit altem Modell 4.2.24 (4.2.22 und 4.2.24 sollen lt. CGM gleich sein) und trotzdem läuft es hier.
Was genau haben Sie dann noch zusätzlich wo eingepflegt- können Sie mal einen Screen schicken? Wenn Sie nichts an den default settings Kocobox dort vorher verändert haben, somit unlogisch erstmal, dass da das Problem liegen soll.
Hab das grad mal näher nochmal hier verfolgt bei mir in der Anlage (eigentlich müsste ich Bürokram machen für die Praxis, aber DAS macht grad mehr Spaß;-)
Also: NSlookup bei mir löst die genannte Zieladresse auf die 100.102.29.10 auf und auf die 100.102.28.10:- das sind bei mir auf der Kocobox bereits fest eingetragene offene Fachdienste bei LAN/WAN-Unterpunkt in der GUI.
Und ich hab jetzt mal wireshark mit Filter ip.addr== 100.102.29.10 mitlaufen lassen bei ERezept Erstellung- und in der Tat haben wir einen Traffic direkt vom Server auf die 100.102.29.10 im Moment der Erstellung also passieren muss da was schon:
Allerdings find ich grad spannend, vielleicht fehlt mir dazu aber auch noch weiteres Wissen und Tiefenverständnis, dass genau DIESER TRaffic jedenfalls lt. Wireshark (vielleicht mach ich da auch grad einen Denkfehler) NICHT noch über den Konnektor zu laufen scheint, sondern direkt der Server Solutio (...100.11) auf den eRezeptFachdienst verbindet - dazu passt für mich auch, dass die Kocobox noch nichts sieht- die dropped zwar in der Tat das ein oder andere IP Paket im Zeitraum , manchmal ist auch eine 100.102.28/29.10 zu filtern, aber so ganz passt das ja nicht da sich ja bei mir sichtlich lt. Wireshark TLS auf diese IP aufbaut.
Meine UTM (Server und Konnektor hier im Parallelbetrieb, alles hinter einer UTM) hatte beim Test auch keine Pakete auf 100.102.29.10- somit gehe ich davon aus, dass der VPN Konnektor genutzt wird- und vielleicht sieht das dann bei Wireshark Serverseitig so normal auch aus dann??!?
Nebenbei sehe ich noch eine weiteren Verbindungspunkt im Wireshark, der ggf. auch noch eine Rolle spielen könnte, sofern wir der Theorie von Solutuio weiter folgen, dass es ein DNS/Fachdiensterreichbarkeitsproblem ist:ich meine das mit erp.app.ti-dienste.de alias die 91.236.122.203. Allerdings Wireshark Test zeigt bei RezeptTest: eine Verbindung auf diese IP ist es nicht, die wird zwar da im TCP Stream erwähnt, aber anscheinend nicht benutzt im Netzwerktraffic.
Trotzdem : In jedem Fall Idee somit mal: als nächstes mal Wireshark mitlaufen lassen auf dem Solutio-Server mit diesem Filter bei Ihnen und schauen, was Wireshark sagt. Vielleicht kann man sehen, wenn es der Verbindungsversuch auf den Fachdienst ist, wo der scheitert, was genau für ein Fehler dann kommt. So könnte man zumindest nochmal gezielter nachweisen ob wir hier normal TLS Handshake haben und es ggf. doch was lokales appseitig Solutio noch ist.
Zusätzlich wär auch nochmal in der Datenbank bei Solutio im pgadmin interessant, was bei Ihnen im Table prescription steht unter "state-before-error".
Hab mir grad mal meine 2 Erstellung_Fehlgeschlagen_Fälle von 10/22 dazu nochmal angeschaut: beide Fälle haben ein "Fachdienst-IDS_Recieved" da bekommen gehabtt, was ich jetzt in Bezug auf das Thema hier mit "bei mir lag es damals nicht an einem Problem "Fachdienst not recieved" liegen könnte.
Hab auch nochmal gezielt geschaut: welcher Traffic kommt, wenn ich eRezept nur bis erstellt laufen lasse: Einen Traffic im VSDM /Kocobox Log hab ich hier erst, wenn das Rezept signiert wurde und status bereitsgestellt hat. Ohne Signierung ist der VSDMLog Kocobox leer. Das passt zu Ihren Ergebnissen. Einzige Logs der Kocobox , die weiterlaufen sind das passive Hintergrundgeschnattere der Kocobox in Sicherheits-/System- und Performanceprotokoll, was aber zwar da ist, aber auch nicht richtig anders aussieht als vor den 5 minuten wo ich eRezept nochmal als Test heut gemacht habe.
Ansonsten : weitere Tatsache ist , kann man auch gut mit wireshark sehen, dass Solutio-Server, wenn ich eRezept App in der Solutio App starte und mitschneide, sich schon im Erstellprozess bis zur Kocobox jedenfalls auch verbindet bereits. Zusätzlich zur direkten Verbindung auf die Fachdienste. Denke dass das der klassischen Prozess Infomodellabfrage/Zertifikatsprüfungen usw. ist, auch hier könnte es natürlich haken, müsste man mit Wireshark also auch nochmal anschauen, ob da was hängt- wobei wenn Karteneinlesen, eAU/EHKP via KIM und KIM usw. laufen halte ich das für unwahrscheinlich, ehrlich gesagt...
Wenn man Wireshark auf einem Client mitlaufen lässt, kann man zusätzlich auch den Zugriff vom Client auf den Charly Server sehen, also http get auf apphosting Service- ich gehe aber davon aus, da sich ja die eRezept-App grundsätzlich öffnet und sich drin arbeiten lässt, dass es auch kein grundsätzliches Problem ist, dass die App gar nicht erst anläuft. Irgendwas danach macht das Problem, aber könnte natürlich auch doch wenn es nicht das mit Verbindung auf den Fachdienst ist was Internes im Prozess sein:
Daher vorsorglich auch nochmal die Frage: Fehlen vielleicht doch Einträge noch bei Solutio selbst, z.B Kassenstempelbereich: Ist bei Einstellungen- Karteireiter Praxis - Radiobutton Praxis - Zahnarzt sichergestellt, dass die Angaben Kassenstempel auch dort alle vollständig sind? Ich meine zu erinnern, dass ich da z.B. das Fehlgeschlagen hatte als da andere Vorgaben eingeführt wurden, die Solutio umsetzen musste- und dass es dann Fehler gab danach, wenn nicht sämtliche Daten inckl. Adresse etc. ausgefüllt sind- da gab es was in einem der letzten Updaterunschreiben (irgendwann ab 10/22 glaub ich) und das könnte z.B. sein, dass es auch an sowas hängt. (sorry, wenn ich das ausdrücklich nochmal frage, vermutlich haben Sie das schon längst geprüft , weil Solutio i.d.Regel da auch als erstes schaut, aber der vollständigkeit halber schreib ich es nochmal mit hier rein.)
Falls es das nicht ist, und Verbindung auf TI Server erezept klappt, scheint es aber irgendwo in diesem Bereich trotzdem zu hängen- evt. könnte man auch nochmal auf dem Server das Phänomen im Webappview+ F12 näher anschauen, manchmal ergeben sich hier auch noch hilfreiche Informationen.
vielen Dank für die ausführlichen Erläuterungen. Ich habe mir nochmal die ganzen Settings seiten Solutio angeschaut. Wir haben aus meiner Sicht alles berücksichtigt.
Ich habe mir jetzt einmal die von Ihnen erwähnte Tabelle angeschaut, überall steht "'FACHDIENST_IDS_RECEIVED'" - Wie haben Sie damals das Problem lösen können ?
Zitat von MarcusD im Beitrag #28überall steht "\'FACHDIENST_IDS_RECEIVED\'" - Wie haben Sie damals das Problem lösen können ?
Aktiv hatte ich nichts gemacht speziell zur Lösung des Problems seinerzeit, da bin ich sicher. Der Fehler trat bei mir ja nur kurz auf und dann nicht mehr. Es ging dann halt einfach wieder nach kurzer Zeit und seitdem bis heute ohne Probleme.
Geändert am Konnektor (Stichwort DNS Resolver) oder in der Charly App Config hatte ich jedenfalls definitiv nichts .
Ich guck Montag aber nochmal gezielt mit 3. und 4. Auge , ob für die Fälle wo was war mit Erstellung fehlgeschlagen damals, mir noch irgendwas Spannendes im zeitlichen Zusammenhang einfällt und vor allem guck ich nochmal welche Testfälle das genau betraf seinerzeit.
TI-Community
»
TI-Nutzung und Nutzen aus Anwendersicht
»
sichere eMail (KIM)
»
Kocobox Firewall blockt Anfragen von Clientsystemen
17.01.2022 11:15 (zuletzt bearbeitet: 16.05.2022 11:20)
Thema drucken
Antworten
security.7z
