Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder einen alternativen Browser verwenden.
ich habe folgendes Problem, wen über terminal mittels openVPN aufbau, funktionert alles ohne Propleme...
Nutze XFCE und importiere die Funktionen aus der vpn.config dann steht zwar das eine Verbindung aufgebaut wurde, aber ich habe praktisch keine Verbindung zu irgendwas...
Woran könnte das liegen? Bzw was geht beim Import Schief? Oder liegt der Fehler doch wieder wo ganz woanders vergraben?
XFCE wird sicherlich die Config auch irgendwo hinschreiben. Vergleich die mal mit deiner Originalen, die funktioniert. Außerdem ist ein Blick ins OpenVPN-Log oftmals hilfreich, im Zweifel das Loglevel hochstellen, damit man mehr sieht.
Würde von OpenVPN eigentlich mittlerweile generell abraten. Wireguard ist Dein Freund, viel einfacher zu konfigurieren und vor allem performanter.
Sehe im zweiten Screenshot schon zwei problematische Stellen: Kompression ist bei OpenVPN schon lange aus Sicherheitsgründen nicht empfohlen UND VPN over TCP ist keine gute Idee, da Du einen TCP-Tunnel erstellst, indem die eigentlichen Pakete wieder TCP nutzen. ---> Extremer Performanceverlust.
Ergänzung ()
Und da ich da vorhin auch "hackthebox" gelesen habe. Das ist jetzt aber nicht so eine Aufgabe wie: "Hier hast du eine Config mit Fehlern, bring die zum laufen.", oder?
Habt sehr vielen Dank euch beiden. @KillerCow
Also das erste ist die verbindung die nicht gehen will, die zweite über OpenVPN... xcfe suche ich noch die file... bzw wie ich das anlegen kann.
└─$ sudo cat /var/log/openvpn/openvpn.log
2024-04-02 16:14:42 Note: --data-cipher-fallback with cipher 'AES-128-CBC' disables data channel offload.
2024-04-02 16:14:42 OpenVPN 2.6.7 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] [DCO]
2024-04-02 16:14:42 library versions: OpenSSL 3.1.5 30 Jan 2024, LZO 2.10
2024-04-02 16:14:42 DCO version: N/A
2024-04-02 16:14:42 TCP/UDP: Preserving recently used remote address: [AF_INET6]64:ff9b::9a39:a464:1337
2024-04-02 16:14:42 Socket Buffers: R=[212992->212992] S=[212992->212992]
2024-04-02 16:14:42 UDPv6 link local: (not bound)
2024-04-02 16:14:42 UDPv6 link remote: [AF_INET6]64:ff9b::9a39:a464:1337
2024-04-02 16:14:48 TLS: Initial packet from [AF_INET6]64:ff9b::9a39:a464:1337, sid=b78c531a 49af197e
2024-04-02 16:14:48 VERIFY OK: depth=1, CN=HackTheBox
2024-04-02 16:14:48 VERIFY KU OK
2024-04-02 16:14:48 Validating certificate extended key usage
2024-04-02 16:14:48 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
2024-04-02 16:14:48 VERIFY EKU OK
2024-04-02 16:14:48 VERIFY OK: depth=0, CN=htb
2024-04-02 16:14:48 Control Channel: TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384, peer certificate: 2048 bits RSA, signature: RSA-SHA256, peer temporary key: 253 bits X25519
2024-04-02 16:14:48 [htb] Peer Connection Initiated with [AF_INET6]64:ff9b::9a39:a464:1337
2024-04-02 16:14:48 TLS: move_session: dest=TM_ACTIVE src=TM_INITIAL reinit_src=1
2024-04-02 16:14:48 TLS: tls_multi_process: initial untrusted session promoted to trusted
2024-04-02 16:14:50 SENT CONTROL [htb]: 'PUSH_REQUEST' (status=1)
2024-04-02 16:14:51 PUSH: Received control message: 'PUSH_REPLY,route 10.10.10.0 255.255.254.0,route 10.129.0.0 255.255.0.0,route-ipv6 dead:beef::/64,explicit-exit-notify,tun-ipv6,route-gateway 10.10.14.1,topology subnet,ping 10,ping-restart 120,ifconfig-ipv6 dead:beef:2::119f/64 dead:beef:2::1,ifconfig 10.10.15.161 255.255.254.0,peer-id 99,cipher AES-256-CBC'
2024-04-02 16:14:51 OPTIONS IMPORT: --ifconfig/up options modified
2024-04-02 16:14:51 OPTIONS IMPORT: route options modified
2024-04-02 16:14:51 OPTIONS IMPORT: route-related options modified
2024-04-02 16:14:51 net_route_v4_best_gw query: dst 0.0.0.0
2024-04-02 16:14:51 net_route_v4_best_gw result: via 192.168.181.23 dev wlan0
2024-04-02 16:14:51 ROUTE_GATEWAY 192.168.181.23/255.255.255.0 IFACE=wlan0 HWADDR=00:28:f8:2a:00:53
2024-04-02 16:14:51 GDG6: remote_host_ipv6=64:ff9b::9a39:a464
2024-04-02 16:14:51 net_route_v6_best_gw query: dst 64:ff9b::9a39:a464
2024-04-02 16:14:51 net_route_v6_best_gw result: via fe80::e873:76ff:fee1:5a4a dev wlan0
2024-04-02 16:14:51 ROUTE6_GATEWAY fe80::e873:76ff:fee1:5a4a IFACE=wlan0
2024-04-02 16:14:51 TUN/TAP device tun1 opened
2024-04-02 16:14:51 net_iface_mtu_set: mtu 1500 for tun1
2024-04-02 16:14:51 net_iface_up: set tun1 up
2024-04-02 16:14:51 net_addr_v4_add: 10.10.15.161/23 dev tun1
2024-04-02 16:14:51 net_iface_mtu_set: mtu 1500 for tun1
2024-04-02 16:14:51 net_iface_up: set tun1 up
2024-04-02 16:14:51 net_addr_v6_add: dead:beef:2::119f/64 dev tun1
2024-04-02 16:14:51 net_route_v4_add: 10.10.10.0/23 via 10.10.14.1 dev [NULL] table 0 metric -1
2024-04-02 16:14:51 sitnl_send: rtnl: generic error (-17): File exists
2024-04-02 16:14:51 NOTE: Linux route add command failed because route exists
2024-04-02 16:14:51 net_route_v4_add: 10.129.0.0/16 via 10.10.14.1 dev [NULL] table 0 metric -1
2024-04-02 16:14:51 sitnl_send: rtnl: generic error (-17): File exists
2024-04-02 16:14:51 NOTE: Linux route add command failed because route exists
2024-04-02 16:14:51 add_route_ipv6(dead:beef::/64 -> dead:beef:2::1 metric -1) dev tun1
2024-04-02 16:14:51 net_route_v6_add: dead:beef::/64 via :: dev tun1 table 0 metric -1
2024-04-02 16:14:51 Initialization Sequence Completed
2024-04-02 16:14:51 Data Channel: cipher 'AES-256-CBC', auth 'SHA256', peer-id: 99, compression: 'lzo'
2024-04-02 16:14:51 Timers: ping 10, ping-restart 120
2024-04-02 16:14:51 Protocol options: explicit-exit-notify 1
2024-04-02 16:15:19 event_wait : Interrupted system call (fd=-1,code=4)
2024-04-02 16:15:19 SIGTERM received, sending exit notification to peer
2024-04-02 16:15:20 delete_route_ipv6(dead:beef::/64)
2024-04-02 16:15:20 net_route_v6_del: dead:beef::/64 via :: dev tun1 table 0 metric -1
2024-04-02 16:15:20 Closing TUN/TAP interface
2024-04-02 16:15:20 net_addr_v4_del: 10.10.15.161 dev tun1
2024-04-02 16:15:20 net_addr_v6_del: dead:beef:2::119f/64 dev tun1
2024-04-02 16:15:20 SIGTERM[soft,exit-with-notification] received, process exiting
@_anonymous0815_
Vielen Dank für den Hinweiss. Nein ich hoffe nicht, möchte ich das schon selber zum laufen bekommen, bzw lernen warum es nicht funktioniert.... ^^ Und über OpenVPN läuft es auch(bei TCP), scheint also nur ein configurationsfehler zu sein?!?! Nur UDP ging letztens irgendwie nicht.😅
Die ovnp ist von denen, sprich wen die "gepfuscht" haben, ist das serverseitig... ^^ Das UDP File habe ich noch nciht zum laufenbekommen. Das soll ja angeblich sehr anfällig gegenüber gegenüber packetlost... TCP bekomme ich über openVPN immerhin ne verbindung. Ist auch nichts wirklich krtisches. Bin halt über Laptop und LTE drinne und möchte halt deren Laps und Kurse machen.
Wireguard, notiere ich mir. Die nutzen halt openVPN oder gar eine HTB Version von Parrot. Vielelicht wechsel ich auch auf diese Distro, wen ich es nicht zum laufen bekommen sollte.
Vielen Dank für den Hinweiss. Nein ich hoffe nicht, möchte ich das schon selber zum laufen bekommen, bzw lernen warum es nicht funktioniert.... ^^ Und über OpenVPN läuft es auch(bei TCP), scheint also nur ein configurationsfehler zu sein?!?! Nur UDP ging letztens irgendwie nicht.😅
Also, kann sein, dass sie serverseitig nur TCP nutzen (wäre bescheuert), aber VPN mit UDP ist absolut kein Problem.
Du hast letztendlich einen UDP-Tunnel und da kann bildlich gesprochen, alles durchfahren oder fließen.
zum Beispiel UDP fährt durch UDP: Packetloss hat keine anderen Auswirkungen als eine stinknormale UDP-Verbindung, es wird einfach ein neues Paket versendet und wenn das nicht ankommt, egal... es kommt ja danach wieder ein Paket.
TCP fährt durch UDP: Packetloss hat auch hier keine fundamental größeten Auswirkungen, außer dass nun nicht einfach ein neues, völlig anderes Paket hinterhergeschickt wird, sondern entweder anhand einer Error Correction die richtigen Daten rekonstruiert werden ODER im schlimmsten Falle kommt es zu einem TCP Retransmit, d.h. das inhaltlich absolut gleiche Paket, wird erneut versandt.
Aber TCP/UDP durch TCP, das sorgt letztendlich dafür, dass der Tunnel an sich jedes eingehende und ausgehende Datenpaket überprüft, auch wenn es nicht vonnöten ist (UDP), als auch wenn es das Datenpaket bereits selbst tun würde(TCP)... doppelt gemoppelt sozusagen, das erhöht die Latenz, die Rechenlast pro Verbindung auf dem Server und auf dem Client und sorgt dafür, dass die nutzbare Datenrate im Tunnel herunterbricht.
Ich habe mal jemanden beim "anmelden" bei Hackthebox gesehen und da ging es schon darum, tiefergreifendes Wissen im Sinne von IT-Systemen zu haben und sich so seinen Invite für die Seite abzuholen. (Irgendeinen Token, habe das selbst nie versucht)
Denen geht es ja schon um Pentesting und Hacking.
Deshalb könnte ich mir auch vorstellen, dass es darum geht, selbstständig eine Lösung für ein gegebenes Problem zu finden.
