staging.inyokaproject.org

DJKUhpisse schrieb:

mollusk schrieb:

ich habe schon mit dem support gesprochen, die sind nicht gesprächig, weil eben privater pc/laptop.

Dann sage denen, dass du das zwingend brauchst. Wahrscheinlich sind die Faul und haben keinen Bock.

Nur mal so allgemein nebenbei: Admins haben Richtlinien (wie sämtliche MA). Die können auch festlegen, daß

• private Rechner nicht supportet werden, das ist in einer seriösen Fa. sowieso absolut normal und richtig,

• ausschließlich bestimmte Betriebssysteme supportet werden.

Ich frage mich eh, wieso hier mit einem privaten Rechner im Home Office gearbeitet werden soll. Sowas ist immer problematisch, rechtlich und die Sicherheit betreffend.

Vielleicht hilft https://techdocs.f5.com/en-us/edge-client-7-1-8/big-ip-access-policy-manager-edge-client-and-application-configuration-7-1-8/clients-for-linux.html weiter, insbesondere der Abschnitt "Requirements for client installation and use on Linux".

Das Paket ppp wird vorausgesetzt, also im Zweifelfall installieren per

sudo apt-get install ppp

von.wert schrieb:

Nur mal so allgemein nebenbei: Admins haben Richtlinien (wie sämtliche MA). Die können auch festlegen, daß

• private Rechner nicht supportet werden, das ist in einer seriösen Fa. sowieso absolut normal und richtig,

• ausschließlich bestimmte Betriebssysteme supportet werden.

Wenn es erlaubt wird, muss auch irgendwo spezifiziert sein, wie die Funktionsweise ist. DNS ist zudem eine betriebssystemübergreifende Sache, ist unter Windows genau wie unter Linux. Dass der Name am autoritativen Server nicht aufgelöst werden kannst, hast du mitbekommen, oder? Wo ist da jetzt der Bezug zu Linux?

Der User liefert zudem zu wenig Information.

Ich frage mich eh, wieso hier mit einem privaten Rechner im Home Office gearbeitet werden soll. Sowas ist immer problematisch, rechtlich und die Sicherheit betreffend.

Rechtlich ist das einwandfrei, wenn es vom AG erlaubt wird und vom AN der Datenschutz eingehalten wird (ist aber dann ggf. dessen Risiko!). Und was die Sicherheit betrifft: Meine Rechner mit Linux sind wesentlich sicherer als so mancher Win-Pc, der seit Jahren in nem Büro ohne Updates vor sich hin gammelt.

Ist aber alles OT hier.

Das Paket ppp wird vorausgesetzt

Bauen denn die anderen User eine PPP-Sitzung auf? Eher ungewöhnlich.

DJKUhpisse schrieb:

DNS ist zudem eine betriebssystemübergreifende Sache, ist unter Windows genau wie unter Linux. Dass der Name am autoritativen Server nicht aufgelöst werden kannst, hast du mitbekommen, oder?

VPN-Clients können durchaus einen zusätzlichen (firmeninternen) DNS-Server "unterjubeln", welcher dann durch den VPN-Tunnel die Auflösung von nicht öffentlich erreichbaren Namensräumen übernimmt.

Zum Thema Privatrechner: https://de.wikipedia.org/wiki/Bring_your_own_device

dingsbums schrieb:

VPN-Clients können durchaus einen zusätzlichen (firmeninternen) DNS-Server "unterjubeln", welcher dann durch den VPN-Tunnel die Auflösung von nicht öffentlich erreichbaren Namensräumen übernimmt.

Das habe ich dem User per PN auch erklärt und gesagt, er soll nachfragen, ob das für diesen Namen so ist. Bisher keine inhaltliche passende Antwort drauf bekommen.

DJKUhpisse schrieb:

Ist aber alles OT hier.

Du hast diesen Unsinn gebracht:

DJKUhpisse schrieb:

mollusk schrieb:

ich habe schon mit dem support gesprochen, die sind nicht gesprächig, weil eben privater pc/laptop.

Dann sage denen, dass du das zwingend brauchst. Wahrscheinlich sind die Faul und haben keinen Bock.

von.wert schrieb:

DJKUhpisse schrieb:

Ist aber alles OT hier.

Du hast diesen Unsinn gebracht:

Falsch, du hast eingeworfen, dass BYOD ein rechtliches Problem sein kann, das ist aber hier nicht das Thema, wir sind kein Juraforum und da der TO das hier macht, gehe ich davon aus, dass das auch erlaubt ist (und wenn nicht ist es sein Problem, nicht das des Threads).

DJKUhpisse, Du willst es nicht verstehen - oder? Du unterstellst dortigen Admins pauschal - ohne auch nur irgendwas näheres darüber zu wissen - sie wären "zu faul und haben keinen Bock".

Damit zeigst Du, daß Du in solche Zusammenhänge in Firmen keinen Einblick hast, aber beleidigst trotzdem eine Gruppe von Leuten.

mollusk schrieb:

also ja, ich weiß, dass von dem privaten windows rechner des kollegen eine verbindung problemlos möglich ist. meine interpretation ist daher: es muss irgendwie gehen. bei dem kollegen gehts ja auch.

OK, dann könnte dein Kollege dir ja ausnahmsweise auch die IP-Adresse mitteilen, unter der der Server erreichbar ist (... denn in Remmina kann man statt den Namen, auch die IP-Adresse vom Server benutzen. Ich benutze privat Remmina und weiß das.). Es muss ja keine permanente Lösung sein, nur _zum temporären testen_, ... obwohl ... es ja auch sein könnte, dass der Server eine statische IP-Adresse hat.

mollusk schrieb:

daher liegt das problem wohl nicht bei denen. irgendwas scheint hier an meinem system zu fehlen.

... und bevor Du in/mit Remmina die von deinem Kollegen mitgeteilte IP-Adresse benutzt/eingibst, machst Du von deinem (privaten) Linux-System, einen Ping auf die IP-Adresse und einen Portscan auf die IP-Adresse und den lauschenden Port des Servers. Z. B. mit:

ping -c 3 <IP-Adresse>
nc -zv <IP-Adresse> <lauschender-Port-am-Server>

(oder gleichwertig). Wenn der Portscan negativ ist, hat der Kollege dir entweder die falsche IP-Adresse mitgeteilt oder Du kannst aus anderen Gründen den lauschenden Port/IP-Adresse nicht erreichen. Ein funktionierende Namensauflösung (DNS), wird dir dann aber auch nicht weiter helfen.

EDIT:

BTW: Wenn dein Kollege die IP-Adresse vom Server, warum auch immer, nicht mitteilen kann, dann den Admin danach fragen.

der support schrieb folgendes:

"Die Fachabteilung kann hier nur folgende Hinweise geben: - zuerst muss natürlich der FQDN als RDP-Ziel angegeben werden: <rechnername><.domain>" → das habe ich ja bereits eingetragen und reicht nicht aus

- "bei der Anmeldung über https://<....> wird den Usern folgende DNS-Server mitgegeben, die natürlich auch explizit befragt werden können: 192.168.X.XXX und 192.168.X.XXX" → ich kann mich über die seite erfolgreich anmelden, dann öffnet sich die startseite "Welcome to F5 Network" und ein pop-up fenster öffnet sich und und zeigt den Status der VPN Verbindung an: connected Es gibt Log-Files darin, die mensch ausklappen und angucken kann: Log File (der punkt funktioniert nicht), routing table, IP Configuration, Connection details. → die Frage ist, ob das mit der Anmeldung die DNS Server doch nicht mitgeliefert werden? Also ein Fehler? Wie könnte ich das prüfen?

Dann teste mal

dig domainname a @IP-vom-DNS

und poste die Antwort.

lubux schrieb:

mollusk schrieb:

also ja, ich weiß, dass von dem privaten windows rechner des kollegen eine verbindung problemlos möglich ist. meine interpretation ist daher: es muss irgendwie gehen. bei dem kollegen gehts ja auch.

OK, dann könnte dein Kollege dir ja ausnahmsweise auch die IP-Adresse mitteilen, unter der der Server erreichbar ist (... denn in Remmina kann man statt den Namen, auch die IP-Adresse vom Server benutzen. Ich benutze privat Remmina und weiß das.). Es muss ja keine permanente Lösung sein, nur _zum temporären testen_, ... obwohl ... es ja auch sein könnte, dass der Server eine statische IP-Adresse hat.

→ ja, aber er benutzt nicht die IP-Adresse, sondern auch den <Rechnername>.<Domain>; auf meine Frage an den Support, ob sie mir die IP-Adresse des Rechners nennen können, sofern stabil, schrieben diese, sie würde sich regelmäßig ändern und es macht daher keinen Sinn

mollusk schrieb:

daher liegt das problem wohl nicht bei denen. irgendwas scheint hier an meinem system zu fehlen.

... und bevor Du in/mit Remmina die von deinem Kollegen mitgeteilte IP-Adresse benutzt/eingibst, machst Du von deinem (privaten) Linux-System, einen Ping auf die IP-Adresse und einen Portscan auf die IP-Adresse und den lauschenden Port des Servers. Z. B. mit:

ping -c 3 <IP-Adresse>
nc -zv <IP-Adresse> <lauschender-Port-am-Server>

(oder gleichwertig). Wenn der Portscan negativ ist, hat der Kollege dir entweder die falsche IP-Adresse mitgeteilt oder Du kannst aus anderen Gründen den lauschenden Port/IP-Adresse nicht erreichen. Ein funktionierende Namensauflösung (DNS), wird dir dann aber auch nicht weiter helfen.

→ bringt es etwas, wenn ich das mit dem Servernamen mal im terminal austeste? wenn ich im vpn verbunden bin, nutzte ich systemweit das vpn oder gibt es eine vpn verbdindung und paralel noch ein zweite - meine reguläre internetverbindung über die fritz-box?

EDIT:

BTW: Wenn dein Kollege die IP-Adresse vom Server, warum auch immer, nicht mitteilen kann, dann den Admin danach fragen.

mollusk schrieb:

→ ja, aber er benutzt nicht die IP-Adresse, sondern auch den <Rechnername>.<Domain>;

Er benutzt sehr wohl die IP-Adresse, wenn auch nicht in der Konfiguration, dafür aber beim herstellen der Verbindung. Und kann jederzeit mit dem geeigneten tool (dig -x, netstat, lsof, tcpdump, etc.) die Adresse auslesen/feststellen und dir mitteilen.

mollusk schrieb:

... auf meine Frage an den Support, ob sie mir die IP-Adresse des Rechners nennen können, sofern stabil, schrieben diese, sie würde sich regelmäßig ändern und es macht daher keinen Sinn

Doch, zum temporärem testen macht es schon Sinn. Denn wenn es mit der IP-Adresse und deiner Konfiguration funktioniert, weißt Du genau, dass Du dich nur noch um die Namensauflösung (DNS) kümmern musst.

DJKUhpisse schrieb:

Dann teste mal

dig domainname a @IP-vom-DNS

und poste die Antwort.

ich habe die erste IP ohne das @ zeichen einegegeben - das ist die antwort:

; <<>> DiG 9.18.1-1ubuntu1.1-Ubuntu <<>> domainname a 192.168.X.XXX ;; global options: +cmd ;; Got answer: ;; →>HEADER<← opcode: QUERY, status: SERVFAIL, id: 33449 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 65494 ;; QUESTION SECTION: ;domainname. IN A

;; Query time: 0 msec ;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP) ;; WHEN: Wed Sep 14 23:23:24 CEST 2022 ;; MSG SIZE rcvd: 39

;; connection timed out; no servers could be reached

–- Test der zweit genannten IP:

; <<>> DiG 9.18.1-1ubuntu1.1-Ubuntu <<>> domainname a 192.168.X.XXX ;; global options: +cmd ;; Got answer: ;; →>HEADER<← opcode: QUERY, status: SERVFAIL, id: 59825 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 65494 ;; QUESTION SECTION: ;domainname. IN A

;; Query time: 0 msec ;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP) ;; WHEN: Wed Sep 14 23:25:02 CEST 2022 ;; MSG SIZE rcvd: 39

;; Got answer: ;; →>HEADER<← opcode: QUERY, status: NXDOMAIN, id: 33666 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 65494 ;; QUESTION SECTION: ;192.168.3.102. IN A

;; AUTHORITY SECTION: . 3600 IN SOA a.root-servers.net. XXX.XXXXXXX.com. 2022091402 XXXX XXX XXXXXXX XXXX

;; Query time: 3820 msec ;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP) ;; WHEN: Wed Sep 14 23:25:26 CEST 2022 ;; MSG SIZE rcvd: 117

Doch, zum temporärem testen macht es schon Sinn. Denn wenn es mit der IP-Adresse und deiner Konfiguration funktioniert, weißt Du genau, dass Du dich nur noch um die Namensauflösung (DNS) kümmern musst.

→ ich verstehe. ich habe aber den support danach gefrag und sie haben mir diese IP Adresse nicht gegeben.