silvertux
Anmeldungsdatum: 18. April 2012
Beiträge: 120
|
Hallo Mitlesende Wo würdest du die Ursache suchen, wenn ssh -vvv user@host folgendes anzeigt? Von Ubuntu 21.04 Desktop nach Ubuntu 20.04 Server debug2: resolve_canonicalize: hostname 10.0.0.111 is address
debug3: expanded UserKnownHostsFile '~/.ssh/known_hosts' -> '/home/user/.ssh/known_hosts'
debug2: ssh_connect_direct
debug1: Connecting to 10.0.0.111 [10.0.0.111] port 22.
... warten ...
debug1: connect to address 10.0.0.111 port 22: Connection timed out Danke für Tipps ☺ chris
|
lubux
Anmeldungsdatum: 21. November 2012
Beiträge: 14359
|
silvertux schrieb: Wo würdest du die Ursache suchen, wenn ssh -vvv user@host folgendes anzeigt? Von Ubuntu 21.04 Desktop nach Ubuntu 20.04 Server
Teste mal auf dem Desktop, ob der Port 22 auf dem Server per Portscan erreichbar ist:
nc -zv 10.0.0.111 22
ping -c 3 10.0.0.111
|
silvertux
(Themenstarter)
Anmeldungsdatum: 18. April 2012
Beiträge: 120
|
@lubux Bei beidem bleibt der cursor darunter stehen. ping: 95 packets transmitted, 0 received, 100% packet loss, time 96232ms
|
lubux
Anmeldungsdatum: 21. November 2012
Beiträge: 14359
|
silvertux schrieb: Bei beidem bleibt der cursor darunter stehen.
Dann kann ssh ja gar nicht funktionieren. Ist die IP 10.0.0.111, die eines VPN-Tunnels?
|
silvertux
(Themenstarter)
Anmeldungsdatum: 18. April 2012
Beiträge: 120
|
Ja, wireguardTunnel. Ich will innerhalb des wireguardNetzes vom Laptop auf den Server. Aber nach 'connecting' gehts nicht weiter. Server systemctl status ssh.service:
Nov 02 10:13:11 VOO sshd[4370]: Accepted publickey for user from 10.0.0.111 port 52906 ssh2: ED25519 SHA256:key...
Nov 02 10:13:11 VOO sshd[4370]: pam_unix(sshd:session): session opened for user user by (uid=0)
Nov 02 10:15:46 VOO sshd[4463]: Accepted publickey for user from 10.0.0.111 port 52930 ssh2: ED25519 SHA256:key...
Nov 02 10:15:46 VOO sshd[4463]: pam_unix(sshd:session): session opened for user user by (uid=0)
Nov 02 11:08:26 VOO sshd[5764]: Accepted publickey for user from 10.0.0.111 port 53654 ssh2: ED25519 SHA256:key...
Nov 02 11:08:26 VOO sshd[5764]: pam_unix(sshd:session): session opened for user user by (uid=0)
|
lubux
Anmeldungsdatum: 21. November 2012
Beiträge: 14359
|
silvertux schrieb: Ja, wireguardTunnel. Ich will innerhalb des wireguardNetzes vom Laptop auf den Server.
Ja, aber bei dir funktioniert dieser WG-Tunnel noch nicht richtig. Bis das nicht der Fall ist, musst Du die ssh-Verbindung via diesen Tunnel gar nicht probieren. Poste vom Client und vom Server die richtig anonymisierten Ausgaben von:
ip a
route -n
wg EDIT: Welche MTU hast Du für den WG-Tunnel (d. h. auf den Peers) konfiguriert?
|
silvertux
(Themenstarter)
Anmeldungsdatum: 18. April 2012
Beiträge: 120
|
Surfen vom Laptop auwärts am Hotspot Handy führt zur eignenIP wie das Handy selbst. Geht also gar nicht über den Tunnel, obwohl beidseits handshake klappt. sudo wg Versuche die Daten so zu zeigen, dass es weiterhilft ...
|
silvertux
(Themenstarter)
Anmeldungsdatum: 18. April 2012
Beiträge: 120
|
peerA
wg0: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN group default qlen 1000
link/none
inet 10.0.0.1/24 scope global wg0
valid_lft forever preferred_lft forever peerB
wg0: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN group default qlen 1000
link/none
inet 10.0.0.111/32 scope global wg0
valid_lft forever preferred_lft forever
|
lubux
Anmeldungsdatum: 21. November 2012
Beiträge: 14359
|
silvertux schrieb: peerA
wg0: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN group default qlen 1000
link/none
inet 10.0.0.1/24 scope global wg0 peerB
wg0: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN group default qlen 1000
link/none
inet 10.0.0.111/32 scope global wg0
Ändere mal temporär (zum testen) bei beiden Peers die MTU auf 1392.
Warum hat die VPN-IP-Adresse beim Peer B eine netmask von 32? Poste mal von beiden Peers, die richtig anonymisierten conf-Dateien. BTW: Der Ping im WG-Tunnel muss/sollte funktionieren.
|
silvertux
(Themenstarter)
Anmeldungsdatum: 18. April 2012
Beiträge: 120
|
Bei den manuell aufgesetzten wireguardInstallationen funktioniert sowohl surfen wie pingen und ssh innerhalb des wireguardNetzes, positive Erfahrung. Doch bei durch Skripts gesteuerten wireguardInstallationen stelle ich fest, dass Fehlerquellen schlecht zu eruieren sind. An den aktuellen confDateien liegt es m.E. kaum, die Ursache liegt eher woanders. interface: peerA (10.0.0.1)
public key: 18d...
private key: (hidden)
listening port: 60606
peer: 34z...
preshared key: (hidden)
endpoint: IPhandy:60606
allowed ips: 10.0.0.111/32
latest handshake: 18 seconds ago
transfer: 612 B received, 1.39 KiB sent
interface: peerB (10.0.0.111)
public key: 34z...
private key: (hidden)
listening port: 60606
fwmark: 0xca6c
peer: 18d...
preshared key: (hidden)
endpoint: dynDNS:60606
allowed ips: 0.0.0.0/0, ::/0
latest handshake: 2 minutes, 43 seconds ago
transfer: 4.57 KiB received, 26.71 KiB sent
|
lubux
Anmeldungsdatum: 21. November 2012
Beiträge: 14359
|
silvertux schrieb: Bei den manuell aufgesetzten wireguardInstallationen funktioniert sowohl surfen wie pingen und ssh innerhalb des wireguardNetzes, positive Erfahrung. Doch bei durch Skripts gesteuerten wireguardInstallationen stelle ich fest, dass Fehlerquellen schlecht zu eruieren sind.
Ich konfiguriere immer manuell und ohne (Installations-)Scripte. Wenn es bei dir manuell funktioniert, warum benutzt dann noch die Scripte?
|
silvertux
(Themenstarter)
Anmeldungsdatum: 18. April 2012
Beiträge: 120
|
Gute Frage 😉 möchte herausfinden, wo der Knopf ist. Auch um wireguard und seine Schwachstellen besser zu verstehen. Werde als nächstes NetworkManager und DNSauflösen nochmals genauer anschauen.
|
lubux
Anmeldungsdatum: 21. November 2012
Beiträge: 14359
|
silvertux schrieb: ... möchte herausfinden, wo der Knopf ist.
Es gibt keinen Knopf. Ich konfiguriere WG nur mit systemd-networkd (... wenn es um Linux geht):
:~ $ ls -la /etc/systemd/network/wg0.*
-rw-r----- 1 root systemd-network 1606 Mar 8 2021 /etc/systemd/network/wg0.netdev
-rw-r--r-- 1 root root 312 Mar 8 2021 /etc/systemd/network/wg0.network :~ $ lsmod | grep -i wireguard
wireguard 69632 0
curve25519_neon 28672 1 wireguard
libcurve25519_generic 24576 2 curve25519_neon,wireguard
libchacha20poly1305 16384 1 wireguard
ip6_udp_tunnel 16384 1 wireguard
udp_tunnel 24576 1 wireguard
libblake2s 16384 1 wireguard
ipv6 495616 1 wireguard
Mehr ist nicht erforderlich, ... keine *.conf-Datei und kein NM.
|