staging.inyokaproject.org

Hi!

Ich bin mir nicht sicher, ob ich hier richtig bin (wegen SSH) oder das Thema eher zu Netzwerkkonfiguration gehört (wegen VPN). Allerdings geht es vermutlich primär um das SSH von Ubuntu, deshalb fand ich es hier passender. Bitte ggf. verschieben.

Ich verwende das VPN meiner Fritzbox 7530 und greife auf zwei Rechner meines Heimnetzes per SSH mit Public Keys zu, einer davon mit Kubuntu 18.04 (PC K) und der andere mit Ubuntu Server 18.04 (PC S).

Seit kurzem kann ich mich vom VPN aus nicht mehr per SSH auf PC K einloggen. Hier der nicht sehr gesprächige Output von ssh:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

$ ssh -vvv 192.168.0.1
OpenSSH_7.6p1 Ubuntu-4ubuntu0.3, OpenSSL 1.0.2n  7 Dec 2017
debug1: Reading configuration data /home/vortex/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug2: resolving "192.168.0.1" port 22
debug2: ssh_connect_direct: needpriv 0
debug1: Connecting to 192.168.0.1 [192.168.0.1] port 22.
debug1: connect to address 192.168.0.1 port 22: Connection refused
ssh: connect to host 192.168.0.1 port 22: Connection refused

In PC S kann ich mich jedoch problemlos im VPN per SSH einloggen und von dort aus wiederum in PC K (gleicher Pubkey). Es funktionieren also sowohl SSH über das VPN und SSH auf PC K grundsätzlich, nur nicht SSH auf PC K per VPN. Ping funktioniert zwischen allen beteiligten Rechnern problemlos.

Der Laptop mit KDE Neon 18.04, von dem ich mich einloggen will, hat direkt im LAN die IP 192.168.0.4 und per VPN die IP 192.168.0.251. Die Dateien /etc/hosts.allow und /etc/hosts.deny auf PC K sind bis auf die Standardkommentarzeilen leer.

Noch 1-2 Wochen zuvor ging alles problemlos, ich bin mir natürlich keiner Schuld bewusst, kann aber einen Gedächtnisverlust nicht ausschließen. 😇 Ich bin momentan an einem anderen Ort als üblich, gehe also von einem anderen Fremdnetz in mein VPN als sonst, aber das sollte innerhalb des VPN egal sein, oder?

Irgendwelche Ideen oder weitere Diagnosetipps?

Dank und Gruß

V.

In der /etc/ssh/sshd_config sind folgende Optionen gesetzt:

PasswordAuthentication no
ChallengeResponseAuthentication no
UsePAM no
X11Forwarding yes
PrintMotd no
AcceptEnv LANG LC_*
Subsystem       sftp    /usr/lib/openssh/sftp-server

Alle anderen sind auskommentiert.

V_for_Vortex schrieb:

Seit kurzem kann ich mich vom VPN aus nicht mehr per SSH auf PC K einloggen. Hier der nicht sehr gesprächige Output von ssh:

1 2 3

debug1: Connecting to 192.168.0.1 [192.168.0.1] port 22. debug1: connect to address 192.168.0.1 port 22: Connection refused ssh: connect to host 192.168.0.1 port 22: Connection refused

Der Laptop mit KDE Neon 18.04, von dem ich mich einloggen will, hat direkt im LAN die IP 192.168.0.4 und per VPN die IP 192.168.0.251.

Funktioniert vom Laptop ein Portscan via VPN? Z. B.:

nc -zv 192.168.0.1 22

?

Leider nein.

$ nc -zv 192.168.0.1 22
nc: connect to 192.168.0.1 port 22 (tcp) failed: Connection refused

Per LAN von PC S zu PC K hingegen gehts:

$ nc -zv 192.168.0.1 22
Connection to 192.168.0.1 22 port [tcp/ssh] succeeded!

Und per VPN vom Laptop zu PC S auch:

$ nc -zv 192.168.0.8 22
Connection to 192.168.0.8 22 port [tcp/ssh] succeeded!

V_for_Vortex schrieb:

Leider nein.

$ nc -zv 192.168.0.1 22
nc: connect to 192.168.0.1 port 22 (tcp) failed: Connection refused

Evtl. ist es dann ein Routingproblem. Schau mal mit tcpdump, auf dem PC K nach, ob der Portscan vom Laptop dort überhaupt ankommt:

sudo tcpdump -c 50 -vvveni <Interface> dst port 22 and src host <"richtige"-IP-Adresse-Laptop>

Okay, also folgendes auf PC K gestartet:

1
2

$ sudo tcpdump -c 50 -vvveni enp0s31f6 dst port 22 and src host 192.168.0.251
tcpdump: listening on enp0s31f6, link-type EN10MB (Ethernet), capture size 262144 bytes

Wenn ich dann vom Laptop mit IP 192.168.0.251 im VPN das nc-Kommando auf die IP 192.168.0.1 des PC K ausführe, gibt es keine weiteren Ausgaben bei dem auf PC K laufenden tcpdump.

V_for_Vortex schrieb:

$ sudo tcpdump -c 50 -vvveni enp0s31f6 dst port 22 and src host 192.168.0.251

Wenn ich dann vom Laptop mit IP 192.168.0.251 im VPN das nc-Kommando auf die IP 192.168.0.1 des PC K ausführe, gibt es keine weiteren Ausgaben bei dem auf PC K laufenden tcpdump.

Wie passt im Filter des tcpdump, das Interface und die VPN-IP-Adresse zusammen? Kann man an diesem Interface überhaupt diese VPN-Adresse sehen? Wenn das aber so OK ist, dann evtl. auf dem Laptop mit tcpdump und dem richtigen Filter versuchen, evtl. bekommt man einen Hinweis wo bzw. von welchem Gerät/IP-Adresse der Portscan (mit nc) geblockt wird.

Was genau meinst Du mit zusammenpassen? Und was meinst Du mit sehen? Hier das Interface auf dem PC K:

3: enp0s31f6: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 30:9c:23:a1:91:be brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.1/24 brd 192.168.0.255 scope global dynamic noprefixroute enp0s31f6
       valid_lft 524525sec preferred_lft 524525sec
    inet6 2001:16b8:48fb:1700:4554:4ac5:5121:5066/64 scope global temporary dynamic 
       valid_lft 7077sec preferred_lft 3477sec
    inet6 2001:16b8:48fb:1700:4ff2:4667:3bb2:ea4a/64 scope global dynamic mngtmpaddr noprefixroute 
       valid_lft 7077sec preferred_lft 3477sec
    inet6 fe80::cacb:f3d9:9d88:2686/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever

Und hier sowohl das WLAN- als auch das VPN-Interface des VPN auf dem Laptop:

3: wlp4s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 80:56:f2:4a:a9:b1 brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.7/24 brd 192.168.0.255 scope global dynamic noprefixroute wlp4s0
       valid_lft 2281sec preferred_lft 2281sec
    inet6 2a0a:a543:2a16:0:2ca0:b899:3332:44d6/64 scope global temporary dynamic 
       valid_lft 3600sec preferred_lft 3600sec
    inet6 2a0a:a543:2a16:0:5228:9b4:c363:f3c0/64 scope global dynamic mngtmpaddr noprefixroute 
       valid_lft 3600sec preferred_lft 3600sec
    inet6 fe80::8e77:9171:81d6:47a0/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever
21: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1412 qdisc fq_codel state UNKNOWN group default qlen 500
    link/none 
    inet 192.168.0.251/24 brd 192.168.0.255 scope global noprefixroute tun0
       valid_lft forever preferred_lft forever
    inet6 fe80::148e:819f:1a:c122/64 scope link stable-privacy 
       valid_lft forever preferred_lft forever

Zwei Dinge sind mir aufgefallen:

1. Ein ping vom Laptop zum PC K kommt mit ca. 8 ms zurück, umgekehrt gibt es jedoch keine Antwort. Der PC S hingegen kann den Laptop mit ca. 26 ms problemlos anpingen, eine ähnliche Zeit braucht ein Ping vom Laptop zum PC S. Der Ping vom Laptop zum PC K ist also weitaus schneller.

2. Außerdem benutzt das WLAN meiner derzeitigen Urlaubsunterkunft dasselbe IP-Netz 192.168.0.x wie mein Heim-LAN und damit auch mein VPN.

Kann es sein, dass SSH und Ping einen Rechner mit der IP 192.168.0.1 im hiesigen WLAN ansprechen, anstatt dieser IP in meinem VPN/LAN? Und das ich nur deswegen zum PC S mit 192.168.0.8 durchkomme, weil im hiesigen WLAN diese IP nicht vergeben ist?

Das sind wilde Hypothesen aus meiner nicht sehr tief reichenden Laien-Sachkenntnis über IP-Netzwerke heraus. Vielleicht kannst Du ja damit etwas anfangen. Ansonsten sag mir, was genau Du noch brauchst.

V_for_Vortex schrieb:

Was genau meinst Du mit zusammenpassen? Und was meinst Du mit sehen? Hier das Interface auf dem PC K:

3: enp0s31f6: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 30:9c:23:a1:91:be brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.1/24 brd 192.168.0.255 scope global dynamic noprefixroute enp0s31f6
       valid_lft 524525sec preferred_lft 524525sec

Ansonsten sag mir, was genau Du noch brauchst.

Wie sind auf den PC K die Ausgaben von:

ip a
ip n s
route -n
sudo netstat -tlpena | grep -i ssh
sudo iptables -nvx -L -t nat
mtr -4nr -c 1 <IP-Adresse-Laptop>

? Und auf dem Laptop die Ausgabe von:

mtr -4nr -c 1 192.168.0.1

? Dass die IP-Netze Urlaub und Heim identisch sind, könnte schon ein Problem sein, ist aber auch vom VPN abhängig. M. E. hat da z. B. OpenVPN eher damit ein Problem als WireGuard.

PC K:

$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: enp3s0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN group default qlen 1000
    link/ether 30:9c:23:a1:91:bf brd ff:ff:ff:ff:ff:ff
3: enp0s31f6: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 30:9c:23:a1:91:be brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.1/24 brd 192.168.0.255 scope global dynamic noprefixroute enp0s31f6
       valid_lft 519505sec preferred_lft 519505sec
    inet6 2001:16b8:48fb:1700:4554:4ac5:5121:5066/64 scope global temporary dynamic 
       valid_lft 6794sec preferred_lft 3194sec
    inet6 2001:16b8:48fb:1700:4ff2:4667:3bb2:ea4a/64 scope global dynamic mngtmpaddr noprefixroute 
       valid_lft 6794sec preferred_lft 3194sec
    inet6 fe80::cacb:f3d9:9d88:2686/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever
4: wlp2s0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether d4:6d:6d:69:9d:3f brd ff:ff:ff:ff:ff:ff

$ ip n s
192.168.0.251 dev enp0s31f6 lladdr 2c:3a:fd:b5:1d:fb STALE
192.168.0.254 dev enp0s31f6 lladdr 2c:3a:fd:b5:1d:fb STALE
192.168.0.7 dev enp0s31f6  FAILED
192.168.0.3 dev enp0s31f6 lladdr 40:61:86:8e:28:f2 STALE
192.168.0.6 dev enp0s31f6 lladdr 00:e0:4c:68:01:f4 STALE
192.168.0.5 dev enp0s31f6 lladdr f8:0d:60:ec:da:7d STALE
192.168.0.8 dev enp0s31f6 lladdr 00:e0:4c:26:35:44 STALE
192.168.0.11 dev enp0s31f6 lladdr dc:a6:32:98:d0:f4 STALE
192.168.0.4 dev enp0s31f6 lladdr 80:56:f2:4a:a9:b1 STALE
2001:16b8:4839:eb00:2e3a:fdff:feb5:1dfb dev enp0s31f6 lladdr 2c:3a:fd:b5:1d:fb router STALE
2001:16b8:48b7:ed00:c158:a15b:bfd8:2d4e dev enp0s31f6 lladdr 00:e0:4c:68:01:f4 STALE
fe80::4447:2c00:c843:89c4 dev enp0s31f6 lladdr 00:e0:4c:68:01:f4 STALE
fe80::2e0:4cff:fe26:3544 dev enp0s31f6 lladdr 00:e0:4c:26:35:44 STALE
2001:16b8:482f:c700:2e3a:fdff:feb5:1dfb dev enp0s31f6 lladdr 2c:3a:fd:b5:1d:fb router STALE
2001:16b8:488b:eb00:2e3a:fdff:feb5:1dfb dev enp0s31f6 lladdr 2c:3a:fd:b5:1d:fb router STALE
2001:16b8:48fb:1700:2e0:4cff:fe26:3544 dev enp0s31f6 lladdr 00:e0:4c:26:35:44 REACHABLE
2001:16b8:48e5:f800:2e3a:fdff:feb5:1dfb dev enp0s31f6 lladdr 2c:3a:fd:b5:1d:fb router STALE
2001:16b8:4861:1e00:2e3a:fdff:feb5:1dfb dev enp0s31f6 lladdr 2c:3a:fd:b5:1d:fb router STALE
2001:16b8:4876:8d00:2e3a:fdff:feb5:1dfb dev enp0s31f6 lladdr 2c:3a:fd:b5:1d:fb router STALE
fe80::2e3a:fdff:feb5:1dfb dev enp0s31f6 lladdr 2c:3a:fd:b5:1d:fb router STALE
fe80::7dc:b095:db16:be17 dev enp0s31f6 lladdr 80:56:f2:4a:a9:b1 STALE
2001:16b8:48fb:1700:2e3a:fdff:feb5:1dfb dev enp0s31f6 lladdr 2c:3a:fd:b5:1d:fb router STALE
2001:16b8:48cd:2b00:2e0:4cff:fe26:3544 dev enp0s31f6 lladdr 00:e0:4c:26:35:44 STALE
2001:16b8:48b7:ed00:2ca0:b899:3332:44d6 dev enp0s31f6 lladdr 80:56:f2:4a:a9:b1 STALE
2001:16b8:481a:1200:2e3a:fdff:feb5:1dfb dev enp0s31f6 lladdr 2c:3a:fd:b5:1d:fb router STALE
2001:16b8:48b7:ed00:2e3a:fdff:feb5:1dfb dev enp0s31f6 lladdr 2c:3a:fd:b5:1d:fb router STALE
2001:16b8:48e2:3800:2e3a:fdff:feb5:1dfb dev enp0s31f6 lladdr 2c:3a:fd:b5:1d:fb router STALE
2001:16b8:48a2:2100:2e3a:fdff:feb5:1dfb dev enp0s31f6 lladdr 2c:3a:fd:b5:1d:fb router STALE
2001:16b8:4861:1e00:f46f:9a30:6ecc:7e0f dev enp0s31f6 lladdr 00:e0:4c:68:01:f4 STALE
2001:16b8:4805:7200:2e3a:fdff:feb5:1dfb dev enp0s31f6 lladdr 2c:3a:fd:b5:1d:fb router STALE
2001:16b8:4844:1800:2e3a:fdff:feb5:1dfb dev enp0s31f6 lladdr 2c:3a:fd:b5:1d:fb router STALE
2001:16b8:48e5:f800:2e0:4cff:fe26:3544 dev enp0s31f6 lladdr 00:e0:4c:26:35:44 STALE
fd00::2e3a:fdff:feb5:1dfb dev enp0s31f6 lladdr 2c:3a:fd:b5:1d:fb router STALE
2001:16b8:48cd:2b00:2e3a:fdff:feb5:1dfb dev enp0s31f6 lladdr 2c:3a:fd:b5:1d:fb router STALE

$ route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.0.254   0.0.0.0         UG    100    0        0 enp0s31f6
169.254.0.0     0.0.0.0         255.255.0.0     U     1000   0        0 enp0s31f6
192.168.0.0     0.0.0.0         255.255.255.0   U     100    0        0 enp0s31f6
22:59:37 vortex@cubi:~$ sudo netstat -tlpena | grep -i ssh 
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      0          33822      1192/sshd           
tcp6       0      0 :::22                   :::*                    LISTEN      0          33824      1192/sshd           
tcp6       0      0 2001:16b8:48fb:1700::22 2001:16b8:48fb:17:57938 ESTABLISHED 0          8140445    12120/sshd: vortex  

$ sudo iptables -nvx -L -t nat
Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes)
    pkts      bytes target     prot opt in     out     source               destination         

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
    pkts      bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
    pkts      bytes target     prot opt in     out     source               destination         

Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
    pkts      bytes target     prot opt in     out     source               destination         

$ mtr -4nr -c 1 192.168.0.251
Start: 2020-08-05T23:00:48+0200
HOST: cubi                        Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 192.168.0.254              0.0%     1    0.5   0.5   0.5   0.5   0.0
  2.|-- ???                       100.0     1    0.0   0.0   0.0   0.0   0.0

Laptop:

$ mtr -4nr -c 1 192.168.0.1
Start: 2020-08-05T23:04:02+0200
HOST: aci                         Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 192.168.0.1                0.0%     1    6.9   6.9   6.9   6.9   0.0

"cubi" ist der Hostname von PC K und "aci" der des Laptops.

Ich gehe jetzt schlafen. Vielen Dank und bis morgen.

V_for_Vortex schrieb:

Laptop:

$ mtr -4nr -c 1 192.168.0.1
Start: 2020-08-05T23:04:02+0200
HOST: aci                         Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 192.168.0.1                0.0%     1    6.9   6.9   6.9   6.9   0.0

V_for_Vortex schrieb:

Kann es sein, dass SSH und Ping einen Rechner mit der IP 192.168.0.1 im hiesigen WLAN ansprechen, anstatt dieser IP in meinem VPN/LAN?

Das kannst Du auf deinem Laptop (im VPN am Urlaubsort), mit einem arping oder/und mit einem arp-scan feststellen, denn damit wird auch die MAC-Adresse des Gerätes mit der IP-Adresse 192.168.0.1 gesehen/gezeigt:

sudo apt-get install iputils-arping arp-scan

sudo arping -c 3 -I <Interface-Laptop> -s 192.168.0.251 192.168.0.1

sudo arp-scan -I <Interface-Laptop> 192.168.0.0/24

Evtl. hat der WLAN-Router am Urlaubsort die IP-Adresse 192.168.0.1. Wie ist am Urlaubsort (im WLAN), auf deinem Laptop die Ausgabe von:

ip a
route -n
ip n s

?

Laptop im VPN:

$ sudo arping -c 3 -I wlp4s0 -s 192.168.0.251 192.168.0.1
ARPING 192.168.0.1 from 192.168.0.251 wlp4s0
Unicast reply from 192.168.0.1 [38:70:0C:35:A1:4F]  5.760ms
Unicast reply from 192.168.0.1 [38:70:0C:35:A1:4F]  2.745ms
Unicast reply from 192.168.0.1 [38:70:0C:35:A1:4F]  2.828ms
Sent 3 probes (1 broadcast(s))
Received 3 response(s)
09:44:24 vortex@aci:~$ sudo arping -c 3 -I tun0 -s 192.168.0.251 192.168.0.1
arping: Device tun0 not available.
09:44:35 vortex@aci:~$ sudo arping -c 3 -I tun0 -s 192.168.0.251 192.168.0.1
arping: Device tun0 not available.
09:44:49 vortex@aci:~$ sudo arp-scan -I wlp4s0 192.168.0.0/24
Interface: wlp4s0, datalink type: EN10MB (Ethernet)
Starting arp-scan 1.9 with 256 hosts (http://www.nta-monitor.com/tools/arp-scan/)
192.168.0.1     38:70:0c:35:a1:4f       (Unknown)

1 packets received by filter, 0 packets dropped by kernel
Ending arp-scan 1.9: 256 hosts scanned in 2.434 seconds (105.18 hosts/sec). 1 responded

$ sudo arp-scan -I wlp4s0 192.168.0.0/24
Interface: wlp4s0, datalink type: EN10MB (Ethernet)
Starting arp-scan 1.9 with 256 hosts (http://www.nta-monitor.com/tools/arp-scan/)
192.168.0.1     38:70:0c:35:a1:4f       (Unknown)

1 packets received by filter, 0 packets dropped by kernel
Ending arp-scan 1.9: 256 hosts scanned in 2.434 seconds (105.18 hosts/sec). 1 responded

$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: enp5s0f1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN group default qlen 1000
    link/ether 08:9e:01:ef:2a:94 brd ff:ff:ff:ff:ff:ff
3: wlp4s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 80:56:f2:4a:a9:b1 brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.7/24 brd 192.168.0.255 scope global dynamic noprefixroute wlp4s0
       valid_lft 3292sec preferred_lft 3292sec
    inet6 2a0a:a543:2a16:0:71d5:44be:4ed5:998a/64 scope global temporary dynamic 
       valid_lft 3599sec preferred_lft 3599sec
    inet6 2a0a:a543:2a16:0:5228:9b4:c363:f3c0/64 scope global dynamic mngtmpaddr noprefixroute 
       valid_lft 3599sec preferred_lft 3599sec
    inet6 fe80::8e77:9171:81d6:47a0/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever

$ route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.0.1     0.0.0.0         UG    600    0        0 wlp4s0
169.254.0.0     0.0.0.0         255.255.0.0     U     1000   0        0 wlp4s0
192.168.0.0     0.0.0.0         255.255.255.0   U     600    0        0 wlp4s0

$ ip n s
192.168.0.1 dev wlp4s0 lladdr 38:70:0c:35:a1:4f REACHABLE
fe80::3a70:cff:fe35:a14f dev wlp4s0 lladdr 38:70:0c:35:a1:4f router REACHABLE

Laptop nur im WLAN ohne VPN:

$ sudo arping -c 3 -I wlp4s0 -s 192.168.0.251 192.168.0.1
bind: Cannot assign requested address

$ sudo arp-scan -I wlp4s0 192.168.0.0/24
Interface: wlp4s0, datalink type: EN10MB (Ethernet)
Starting arp-scan 1.9 with 256 hosts (http://www.nta-monitor.com/tools/arp-scan/)
192.168.0.1     38:70:0c:35:a1:4f       (Unknown)
192.168.0.6     5c:09:47:40:ec:6b       (Unknown)

2 packets received by filter, 0 packets dropped by kernel
Ending arp-scan 1.9: 256 hosts scanned in 2.247 seconds (113.93 hosts/sec). 2 responded

$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: enp5s0f1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN group default qlen 1000
    link/ether 08:9e:01:ef:2a:94 brd ff:ff:ff:ff:ff:ff
3: wlp4s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 80:56:f2:4a:a9:b1 brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.7/24 brd 192.168.0.255 scope global dynamic noprefixroute wlp4s0
       valid_lft 3292sec preferred_lft 3292sec
    inet6 2a0a:a543:2a16:0:71d5:44be:4ed5:998a/64 scope global temporary dynamic 
       valid_lft 3599sec preferred_lft 3599sec
    inet6 2a0a:a543:2a16:0:5228:9b4:c363:f3c0/64 scope global dynamic mngtmpaddr noprefixroute 
       valid_lft 3599sec preferred_lft 3599sec
    inet6 fe80::8e77:9171:81d6:47a0/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever

$ route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.0.1     0.0.0.0         UG    600    0        0 wlp4s0
169.254.0.0     0.0.0.0         255.255.0.0     U     1000   0        0 wlp4s0
192.168.0.0     0.0.0.0         255.255.255.0   U     600    0        0 wlp4s0

$ ip n s
192.168.0.1 dev wlp4s0 lladdr 38:70:0c:35:a1:4f REACHABLE
fe80::3a70:cff:fe35:a14f dev wlp4s0 lladdr 38:70:0c:35:a1:4f router REACHABLE

Die MAC-Adresse von 192.168.0.1 ist identisch mit und ohne VPN, also ist das der Grund dafür, dass ich PC K nicht erreiche. Fragt sich, warum das so ist und wie ich es beheben kann, möglichst ohne die IP von PC K zu ändern, weil dort ein paar Dienste laufen, auf die andere Rechner zugreifen. Hast Du dazu auch Ideen?

V_for_Vortex schrieb:

... wie ich es beheben kann, möglichst ohne die IP von PC K zu ändern, weil dort ein paar Dienste laufen, auf die andere Rechner zugreifen. Hast Du dazu auch Ideen?

Installiere WireGuard auf deinem PC K (bzw. auf deinem Laptop) und stelle mit WG eine peer-to-peer-Verbindung zwischen deinem Laptop und dem PC K her.

Danke, aber laut Wireguard müsste ich dafür eine Fremdquelle benutzen, was ich nur aus wichtigen Gründen mache, und vorübergehende Probleme im Urlaub gehören eher nicht dazu. Ich brauche die direkte Verbindung eigentlich nur aus Bequemlichkeit und für ein paar direkte Dienste wie z.B. Unison.

Da SSH vom Laptop zum PC S und von dort zum PC K funktioniert: Kann ich eventuell mit Ubuntu-Bordmitteln eine SSH-Weiterleitung auf PC S einrichten?

V_for_Vortex schrieb:

Da SSH vom Laptop zum PC S und von dort zum PC K funktioniert: Kann ich eventuell mit Ubuntu-Bordmitteln eine SSH-Weiterleitung auf PC S einrichten?

Du kannst SSH mit einem Jumphost benutzen, um über diesen Host an PC K zu kommen.

ssh -J PC S PC K