Devices via VPN ins Lokale Netzwerk brücken

mat6937 · Beitrag von **mat6937** » 10.03.2020 15:32:34

Knogle hat geschrieben:
10.03.2020 15:12:07
Meine Configs schauen nun so aus, jedoch kann ich leider die jeweils andere Seite nicht anpingen.
Brauche ich weiterhin noch bestimmte iptable rules?

Versuch mal mit:

Server:

Code: Alles auswählen

[Interface]
Address = 10.0.0.1/24
ListenPort = 5555
PrivateKey = Privater Key Standort DE

[Peer]
PublicKey = Public Key Standort Other
AllowedIPs = 10.0.0.2/32

Client:

Code: Alles auswählen

[Interface]
Address = 10.0.0.2/24
ListenPort = 5555
PrivateKey = Privater Key Standort Other

[Peer]
PublicKey = Public Key Standort DE
AllowedIPs = 10.0.0.1/32
Endpoint = tld-domain:5555
PersistentKeepalive = 30

und als iptables-Rules, jeweils:

Code: Alles auswählen

iptables -t nat -I POSTROUTING 1 -o eth0 -j MASQUERADE
iptables -t nat -I POSTROUTING 2 -o wg0 -j MASQUERADE

(evtl. später auch noch in der Forward-chain und das forward mit sysctl).

Testen auf dem Server mit:

Code: Alles auswählen

wg
ping -c 3 10.0.0.2

bluestar · Beitrag von **bluestar** » 10.03.2020 15:32:50

Hast du den Port 5555 udp auch in DE entsprechend in deiner Fritzbox an den Wireguard Server durchgereicht? Was sagt denn wg show

Knogle · Beitrag von **Knogle** » 10.03.2020 15:46:13

Die Variante von mat probiere ich gleich auch mal.

Hier mal wg show vom Standort DE aus.

Code: Alles auswählen

root@wireguard:~# wg show
interface: wg0
  public key: dnjR6hsnRNTHP8qw2Pm6T+WLZwH6HWQYgNECdH0Wfjc=
  private key: (hidden)
  listening port: 5555

ipv4 Forwarding Standort DE ist aktiv.

Hier die Portfreigabe von der Fritte.

Code: Alles auswählen

10.03.2020 13:15 	UDP 	5555 	wireguard (192.168.2.57) 	5555

Die Route in der Fritte habe ich schonmal erstellt, jedoch ging halt wegen des aktuellen problems

Code: Alles auswählen

ip route add 192.168.1.0/24 via 10.0.0.2

nicht.
Bei mir ist 192.168.2.0 das Netzwerk Zuhause, und 192.168.1.0 das Netzwerk other nur damit es keine Verwechslungen gibt.

Wird bei Wireguard evtl. irgendwo was geloggt?

mat6937 · Beitrag von **mat6937** » 10.03.2020 16:16:48

Knogle hat geschrieben:
10.03.2020 15:46:13
Wird bei Wireguard evtl. irgendwo was geloggt?

Ja, ... leider. Z. B.:

Code: Alles auswählen

latest handshake: 1 minute, 33 seconds ago
  transfer: 54.28 KiB received, 85.72 KiB sent

EDIT:

BTW: Mit:

Code: Alles auswählen

modprobe wireguard && echo module wireguard +p > /sys/kernel/debug/dynamic_debug/control

kannst man auch nach dmesg loggen lassen (... wenn wireguard im Kernel implementiert ist, und nicht im user space, wie z. B. bei FreeBSD).

EDIT 2:

Mit:

Code: Alles auswählen

modprobe wireguard && echo module wireguard -p > /sys/kernel/debug/dynamic_debug/control

kann man das loggen/schreiben nach dmesg, stoppen/unterbrechen.

Knogle · Beitrag von **Knogle** » 10.03.2020 16:31:46

Danke dir, super!
Jetzt haben wir schonmal das hier.
Vom Wireguard Standort DE
Irgendwas scheint da ja schon zu funken, weil die angegebene IP ist von meinem Standort "Other".

Bei meinem OpenWRT Device kann ich leider nicht auf diese Art loggen.

Code: Alles auswählen

root@wireguard:~# dmesg | egrep --color "wireguard"
[    1.856766] systemd[1]: Set hostname to <wireguard>.
[  199.887411] wireguard: loading out-of-tree module taints kernel.
[  199.888223] wireguard: module verification failed: signature and/or required key missing - tainting kernel
[  199.890698] wireguard: WireGuard 0.0.20200215 loaded. See www.wireguard.com for information.
[  199.891549] wireguard: Copyright (C) 2015-2019 Jason A. Donenfeld <Jason@zx2c4.com>. All Rights Reserved.
[ 6869.259562] wireguard: wg0: Invalid MAC of handshake, dropping packet from 189.40.77.52:65278
[ 6874.747620] wireguard: wg0: Invalid MAC of handshake, dropping packet from 189.40.77.52:65278
[ 6880.110923] wireguard: wg0: Invalid MAC of handshake, dropping packet from 189.40.77.52:65278
[ 6886.593877] wireguard: wg0: Invalid MAC of handshake, dropping packet from 189.40.77.52:65278
[ 6890.988796] wireguard: wg0: Invalid MAC of handshake, dropping packet from 189.40.77.52:65278
[ 6895.809963] wireguard: wg0: Interface deleted
[ 6895.837094] wireguard: wg0: Interface created
[ 6895.854286] wireguard: wg0: Peer 1 created
[ 6896.039231] wireguard: wg0: Receiving handshake initiation from peer 1 (189.40.77.52:65278)
[ 6896.039235] wireguard: wg0: Sending handshake response to peer 1 (189.40.77.52:65278)
[ 6896.039595] wireguard: wg0: Keypair 1 created for peer 1
[ 6896.323101] wireguard: wg0: Receiving keepalive packet from peer 1 (189.40.77.52:65278)

mat6937 · Beitrag von **mat6937** » 10.03.2020 16:36:00

Knogle hat geschrieben:
10.03.2020 16:31:46
Irgendwas scheint da ja schon zu funken, weil die angegebene IP ist von meinem Standort "Other".

Naja, Du musst die Konfiguration zeigen und sagen/schreiben, ob Server und Client sich gegenseitig pingen können.

Knogle hat geschrieben:
10.03.2020 16:31:46
Bei meinem OpenWRT Device kann ich leider nicht auf diese Art loggen.

Dann wird wireguard bei OpenWRT noch nicht im Kernel implementiert sein, sondern nur im user space.

EDIT:

Siehe z. B. auch die Ausgaben von:

Code: Alles auswählen

modinfo wireguard
ps aux | grep -i [w]g

Knogle · Beitrag von **Knogle** » 10.03.2020 16:45:35

So, wg sieht schon interessant aus wie ich finde vom Server.
Habe nun deine angepasste Konfig genommen, jedoch erstmal noch das andere allowed ip drin gelassen.

Einmal vom Server

Code: Alles auswählen

wg
interface: wg0
  public key: Ihs8hitC309KYk6j2lhQOHh48K5ne3M85qX1vV15pFw=
  private key: (hidden)
  listening port: 5555

peer: dnjR6hsnRNTHP8qw2Pm6T+WLZwH6HWQYgNECdH0Wfjc=
  endpoint: 189.40.77.52:65278
  allowed ips: 10.0.0.2/32, 192.168.1.0/24
  latest handshake: 4 seconds ago
  transfer: 488 B received, 1.18 KiB sent

Hier vom OpenWRT device

Code: Alles auswählen

root@OpenWrt:~# wg
interface: wg0
  public key: dnjR6hsnRNTHP8qw2Pm6T+WLZwH6HWQYgNECdH0Wfjc=
  private key: (hidden)
  listening port: 5555

peer: Ihs8hitC309KYk6j2lhQOHh48K5ne3M85qX1vV15pFw=
  endpoint: 78.35.90.26:5555
  allowed ips: 10.0.0.1/32, 192.168.2.0/24
  latest handshake: 1 minute, 27 seconds ago
  transfer: 1.63 KiB received, 115.50 KiB sent
  persistent keepalive: every 30 seconds

Anpingen noch nicht moeglich.
Den Rest werde ich aus zeitgruenden erst gleich checken.

mat6937 · Beitrag von **mat6937** » 10.03.2020 16:52:24

Knogle hat geschrieben:
10.03.2020 16:45:35
..., jedoch erstmal noch das andere allowed ip drin gelassen.

Aber genau das sollst Du für den 1. Test, _nicht_ machen.

EDIT:

Code: Alles auswählen

AllowedIPs — a comma-separated list of IP (v4 or v6) addresses with CIDR masks from which incoming traf‐
              fic  for  this  peer  is  allowed and to which outgoing traffic for this peer is directed. The catch-all
              0.0.0.0/0 may be specified for matching all IPv4 addresses, and ::/0 may be specified for  matching  all
              IPv6 addresses. May be specified multiple times.

Routing & Network Namespace Integration

bluestar · Beitrag von **bluestar** » 10.03.2020 19:48:25

Knogle hat geschrieben:
10.03.2020 16:45:35

Anpingen noch nicht moeglich.
Den Rest werde ich aus zeitgruenden erst gleich checken.

Was sagt denn auf beiden Seiten
- ip addr show dev wg0
- ip route show dev wg0

Du pingst hoffentlich auf den Linux Systemen, wo du Wireguard eingerichtet hast, oder irgendwo aus deinem LAN?

Knogle · Beitrag von **Knogle** » 10.03.2020 20:00:52

bluestar hat geschrieben:
10.03.2020 19:48:25

Knogle hat geschrieben:
10.03.2020 16:45:35

Anpingen noch nicht moeglich.
Den Rest werde ich aus zeitgruenden erst gleich checken.
Was sagt denn auf beiden Seiten
- ip addr show dev wg0
- ip route show dev wg0

Du pingst hoffentlich auf den Linux Systemen, wo du Wireguard eingerichtet hast, oder irgendwo aus deinem LAN?

Genau, ich pinge auf beiden Linux Systemen wo auch Wireguard rennt.

ip addr show dev wg0

Standort Other:

Code: Alles auswählen

8: wg0: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN group default qlen 1000
    link/none 
    inet 10.0.0.2/24 brd 10.0.0.255 scope global wg0
       valid_lft forever preferred_lft forever

Standort DE:

Code: Alles auswählen

6: 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

ip route show dev wg0

Standort Other:

Code: Alles auswählen

10.0.0.0/24 proto kernel scope link src 10.0.0.2

Standort DE:

Code: Alles auswählen

10.0.0.0/24 proto kernel scope link src 10.0.0.1 
192.168.1.0/24 scope link

Werde aber erstmal wie von mat beschrieben die 192.168xxx Teile aus den Configs rausmachen.

EDIT: Leider auch so ist ein Anpingen nicht drin.

mat6937 · Beitrag von **mat6937** » 10.03.2020 20:11:13

Knogle hat geschrieben:
10.03.2020 20:00:52
EDIT: Leider auch so ist ein Anpingen nicht drin.

Poste deine Konfiguration, die Ausgaben von 2x:

Code: Alles auswählen

wg

und wie Du gepingt hast.

bluestar · Beitrag von **bluestar** » 10.03.2020 20:13:05

Die /24 auf dein Interface IPs ist falsch: Du solltest /32 verwenden.

Gibt‘s noch iptables Regeln, die stören können?

mat6937 · Beitrag von **mat6937** » 10.03.2020 20:16:40

bluestar hat geschrieben:
10.03.2020 20:13:05
Die /24 auf dein Interface IPs ist falsch:

Nein, die ist nicht falsch. Hier funktioniert das so.

Knogle · Beitrag von **Knogle** » 10.03.2020 20:17:31

Vielleicht höchstens die Firewall Regeln bei OpenWRT.

Hier mal Ping vom Standort DE aus.

Code: Alles auswählen

root@wireguard:~# ping -c3 10.0.0.2
PING 10.0.0.2 (10.0.0.2) 56(84) bytes of data.
From 10.0.0.1 icmp_seq=1 Destination Host Unreachable
ping: sendmsg: Destination address required
From 10.0.0.1 icmp_seq=2 Destination Host Unreachable
ping: sendmsg: Destination address required
From 10.0.0.1 icmp_seq=3 Destination Host Unreachable
ping: sendmsg: Destination address required

--- 10.0.0.2 ping statistics ---
3 packets transmitted, 0 received, +3 errors, 100% packet loss, time 2039ms

root@wireguard:~# ping -c3 10.0.0.1
PING 10.0.0.1 (10.0.0.1) 56(84) bytes of data.
64 bytes from 10.0.0.1: icmp_seq=1 ttl=64 time=0.041 ms
64 bytes from 10.0.0.1: icmp_seq=2 ttl=64 time=0.071 ms
64 bytes from 10.0.0.1: icmp_seq=3 ttl=64 time=0.053 ms

--- 10.0.0.1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2044ms
rtt min/avg/max/mdev = 0.041/0.055/0.071/0.012 ms
root@wireguard:~#

Standort Other.

Code: Alles auswählen

root@OpenWrt:~# ping -c3 10.0.0.1
PING 10.0.0.1 (10.0.0.1): 56 data bytes

--- 10.0.0.1 ping statistics ---
3 packets transmitted, 0 packets received, 100% packet loss
root@OpenWrt:~# ping -c3 10.0.0.2
PING 10.0.0.2 (10.0.0.2): 56 data bytes
64 bytes from 10.0.0.2: seq=0 ttl=64 time=0.660 ms
64 bytes from 10.0.0.2: seq=1 ttl=64 time=0.334 ms
64 bytes from 10.0.0.2: seq=2 ttl=64 time=0.332 ms

--- 10.0.0.2 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 0.332/0.442/0.660 ms

iptables -S DE

Code: Alles auswählen

iptables -S
-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT

iptables -S Other

Code: Alles auswählen

root@OpenWrt:~# iptables -S
-P INPUT ACCEPT
-P FORWARD DROP
-P OUTPUT ACCEPT
-N forwarding_lan_rule
-N forwarding_rule
-N forwarding_wan_rule
-N input_lan_rule
-N input_rule
-N input_wan_rule
-N output_lan_rule
-N output_rule
-N output_wan_rule
-N reject
-N syn_flood
-N zone_lan_dest_ACCEPT
-N zone_lan_forward
-N zone_lan_input
-N zone_lan_output
-N zone_lan_src_ACCEPT
-N zone_wan_dest_ACCEPT
-N zone_wan_dest_REJECT
-N zone_wan_forward
-N zone_wan_input
-N zone_wan_output
-N zone_wan_src_REJECT
-A INPUT -i lo -m comment --comment "!fw3" -j ACCEPT
-A INPUT -m comment --comment "!fw3: Custom input rule chain" -j input_rule
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -m comment --comment "!fw3" -j ACCEPT
-A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -m comment --comment "!fw3" -j syn_flood
-A INPUT -i br-lan -m comment --comment "!fw3" -j zone_lan_input
-A INPUT -i wg0 -m comment --comment "!fw3" -j zone_lan_input
-A INPUT -i eth0.2 -m comment --comment "!fw3" -j zone_wan_input
-A INPUT -i wlan0 -m comment --comment "!fw3" -j zone_wan_input
-A FORWARD -m comment --comment "!fw3: Custom forwarding rule chain" -j forwarding_rule
-A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -m comment --comment "!fw3" -j ACCEPT
-A FORWARD -i br-lan -m comment --comment "!fw3" -j zone_lan_forward
-A FORWARD -i wg0 -m comment --comment "!fw3" -j zone_lan_forward
-A FORWARD -i eth0.2 -m comment --comment "!fw3" -j zone_wan_forward
-A FORWARD -i wlan0 -m comment --comment "!fw3" -j zone_wan_forward
-A FORWARD -m comment --comment "!fw3" -j reject
-A OUTPUT -o lo -m comment --comment "!fw3" -j ACCEPT
-A OUTPUT -m comment --comment "!fw3: Custom output rule chain" -j output_rule
-A OUTPUT -m conntrack --ctstate RELATED,ESTABLISHED -m comment --comment "!fw3" -j ACCEPT
-A OUTPUT -o br-lan -m comment --comment "!fw3" -j zone_lan_output
-A OUTPUT -o wg0 -m comment --comment "!fw3" -j zone_lan_output
-A OUTPUT -o eth0.2 -m comment --comment "!fw3" -j zone_wan_output
-A OUTPUT -o wlan0 -m comment --comment "!fw3" -j zone_wan_output
-A reject -p tcp -m comment --comment "!fw3" -j REJECT --reject-with tcp-reset
-A reject -m comment --comment "!fw3" -j REJECT --reject-with icmp-port-unreachable
-A syn_flood -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -m limit --limit 25/sec --limit-burst 50 -m comment --comment "!fw3" -j RETURN
-A syn_flood -m comment --comment "!fw3" -j DROP
-A zone_lan_dest_ACCEPT -o br-lan -m comment --comment "!fw3" -j ACCEPT
-A zone_lan_dest_ACCEPT -o wg0 -m comment --comment "!fw3" -j ACCEPT
-A zone_lan_forward -m comment --comment "!fw3: Custom lan forwarding rule chain" -j forwarding_lan_rule
-A zone_lan_forward -m comment --comment "!fw3: Zone lan to wan forwarding policy" -j zone_wan_dest_ACCEPT
-A zone_lan_forward -m conntrack --ctstate DNAT -m comment --comment "!fw3: Accept port forwards" -j ACCEPT
-A zone_lan_forward -m comment --comment "!fw3" -j zone_lan_dest_ACCEPT
-A zone_lan_input -m comment --comment "!fw3: Custom lan input rule chain" -j input_lan_rule
-A zone_lan_input -m conntrack --ctstate DNAT -m comment --comment "!fw3: Accept port redirections" -j ACCEPT
-A zone_lan_input -m comment --comment "!fw3" -j zone_lan_src_ACCEPT
-A zone_lan_output -m comment --comment "!fw3: Custom lan output rule chain" -j output_lan_rule
-A zone_lan_output -m comment --comment "!fw3" -j zone_lan_dest_ACCEPT
-A zone_lan_src_ACCEPT -i br-lan -m conntrack --ctstate NEW,UNTRACKED -m comment --comment "!fw3" -j ACCEPT
-A zone_lan_src_ACCEPT -i wg0 -m conntrack --ctstate NEW,UNTRACKED -m comment --comment "!fw3" -j ACCEPT
-A zone_wan_dest_ACCEPT -o eth0.2 -m conntrack --ctstate INVALID -m comment --comment "!fw3: Prevent NAT leakage" -j DROP
-A zone_wan_dest_ACCEPT -o eth0.2 -m comment --comment "!fw3" -j ACCEPT
-A zone_wan_dest_ACCEPT -o wlan0 -m conntrack --ctstate INVALID -m comment --comment "!fw3: Prevent NAT leakage" -j DROP
-A zone_wan_dest_ACCEPT -o wlan0 -m comment --comment "!fw3" -j ACCEPT
-A zone_wan_dest_REJECT -o eth0.2 -m comment --comment "!fw3" -j reject
-A zone_wan_dest_REJECT -o wlan0 -m comment --comment "!fw3" -j reject
-A zone_wan_forward -m comment --comment "!fw3: Custom wan forwarding rule chain" -j forwarding_wan_rule
-A zone_wan_forward -p esp -m comment --comment "!fw3: Allow-IPSec-ESP" -j zone_lan_dest_ACCEPT
-A zone_wan_forward -p udp -m udp --dport 500 -m comment --comment "!fw3: Allow-ISAKMP" -j zone_lan_dest_ACCEPT
-A zone_wan_forward -m conntrack --ctstate DNAT -m comment --comment "!fw3: Accept port forwards" -j ACCEPT
-A zone_wan_forward -m comment --comment "!fw3" -j zone_wan_dest_REJECT
-A zone_wan_input -m comment --comment "!fw3: Custom wan input rule chain" -j input_wan_rule
-A zone_wan_input -p udp -m udp --dport 68 -m comment --comment "!fw3: Allow-DHCP-Renew" -j ACCEPT
-A zone_wan_input -p icmp -m icmp --icmp-type 8 -m comment --comment "!fw3: Allow-Ping" -j ACCEPT
-A zone_wan_input -p igmp -m comment --comment "!fw3: Allow-IGMP" -j ACCEPT
-A zone_wan_input -p udp -m comment --comment "!fw3: Allow-WireGuard" -j ACCEPT
-A zone_wan_input -m conntrack --ctstate DNAT -m comment --comment "!fw3: Accept port redirections" -j ACCEPT
-A zone_wan_input -m comment --comment "!fw3" -j zone_wan_src_REJECT
-A zone_wan_output -m comment --comment "!fw3: Custom wan output rule chain" -j output_wan_rule
-A zone_wan_output -m comment --comment "!fw3" -j zone_wan_dest_ACCEPT
-A zone_wan_src_REJECT -i eth0.2 -m comment --comment "!fw3" -j reject
-A zone_wan_src_REJECT -i wlan0 -m comment --comment "!fw3" -j reject

Habe erstmal eine Firewall Regel nach einem Reddit Link dementsprechend hier gesetzt.

Code: Alles auswählen

Name: WireGuard
Protocol: UDP
External Zone: WAN
External Port: 5555
Internal Zone: LAN
Internal IP Address: <The IP address of your device, mine is 192.168.1.1>
Internal Port: 5555

EDIT: Gut, hat leider auch nix geaendert.

mat6937 · Beitrag von **mat6937** » 10.03.2020 20:24:47

Knogle hat geschrieben:
10.03.2020 20:17:31
Vielleicht höchstens die Firewall Regeln bei OpenWRT.

Dann deaktiviere temporär die iptables-Regeln in OpenWRT.

Knogle · Beitrag von **Knogle** » 10.03.2020 20:33:16

mat6937 hat geschrieben:
10.03.2020 20:24:47

Knogle hat geschrieben:
10.03.2020 20:17:31
Vielleicht höchstens die Firewall Regeln bei OpenWRT.
Dann deaktiviere temporär die iptables-Regeln in OpenWRT.

Vielen Dank! Da sind wir schonmal sehr viel weiter.

Von beiden Seiten klappt das Anpingen jetzt.

Code: Alles auswählen

root@OpenWrt:~# iptables -F
root@OpenWrt:~# iptables -X
root@OpenWrt:~# iptables -P INPUT ACCEPT
root@OpenWrt:~# iptables -P FORWARD ACCEPT
root@OpenWrt:~# iptables -P OUTPUT ACCEPT

root@OpenWrt:~# ping -c3 10.0.0.1
PING 10.0.0.1 (10.0.0.1): 56 data bytes
64 bytes from 10.0.0.1: seq=0 ttl=64 time=646.639 ms
64 bytes from 10.0.0.1: seq=1 ttl=64 time=858.321 ms
64 bytes from 10.0.0.1: seq=2 ttl=64 time=480.279 ms

--- 10.0.0.1 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 480.279/661.746/858.321 ms

Wie muss ich nun vorgehen um das gewünsche Verhalten zu erhalten? Einfach weiter der Anleitung von bluestar auf vorheriger Seite folgen?

mat6937 · Beitrag von **mat6937** » 10.03.2020 20:36:35

Knogle hat geschrieben:
10.03.2020 20:33:16
root@OpenWrt:~# ping -c3 10.0.0.1
PING 10.0.0.1 (10.0.0.1): 56 data bytes
64 bytes from 10.0.0.1: seq=0 ttl=64 time=646.639 ms
64 bytes from 10.0.0.1: seq=1 ttl=64 time=858.321 ms
64 bytes from 10.0.0.1: seq=2 ttl=64 time=480.279 ms

Wie ist der ping von der anderen Seite?

Knogle · Beitrag von **Knogle** » 10.03.2020 20:38:44

mat6937 hat geschrieben:
10.03.2020 20:36:35

Knogle hat geschrieben:
10.03.2020 20:33:16
root@OpenWrt:~# ping -c3 10.0.0.1
PING 10.0.0.1 (10.0.0.1): 56 data bytes
64 bytes from 10.0.0.1: seq=0 ttl=64 time=646.639 ms
64 bytes from 10.0.0.1: seq=1 ttl=64 time=858.321 ms
64 bytes from 10.0.0.1: seq=2 ttl=64 time=480.279 ms

Wie ist der ping von der anderen Seite?

Schaut etwa so aus.
Soll erstmal nur provisorisch via Handy AP gehen, damit ich dann die funktionierende Variante hier ans Nachbar WLAN anbinden kann.

Code: Alles auswählen

64 bytes from 10.0.0.2: icmp_seq=488 ttl=64 time=267 ms
64 bytes from 10.0.0.2: icmp_seq=489 ttl=64 time=518 ms
64 bytes from 10.0.0.2: icmp_seq=490 ttl=64 time=312 ms
64 bytes from 10.0.0.2: icmp_seq=491 ttl=64 time=607 ms
64 bytes from 10.0.0.2: icmp_seq=492 ttl=64 time=265 ms
64 bytes from 10.0.0.2: icmp_seq=493 ttl=64 time=293 ms
64 bytes from 10.0.0.2: icmp_seq=494 ttl=64 time=269 ms
64 bytes from 10.0.0.2: icmp_seq=495 ttl=64 time=827 ms
64 bytes from 10.0.0.2: icmp_seq=496 ttl=64 time=292 ms
64 bytes from 10.0.0.2: icmp_seq=497 ttl=64 time=290 ms
64 bytes from 10.0.0.2: icmp_seq=498 ttl=64 time=273 ms
64 bytes from 10.0.0.2: icmp_seq=499 ttl=64 time=273 ms
64 bytes from 10.0.0.2: icmp_seq=500 ttl=64 time=278 ms
64 bytes from 10.0.0.2: icmp_seq=501 ttl=64 time=351 ms
64 bytes from 10.0.0.2: icmp_seq=502 ttl=64 time=430 ms
64 bytes from 10.0.0.2: icmp_seq=503 ttl=64 time=275 ms
64 bytes from 10.0.0.2: icmp_seq=504 ttl=64 time=312 ms
64 bytes from 10.0.0.2: icmp_seq=505 ttl=64 time=274 ms
64 bytes from 10.0.0.2: icmp_seq=506 ttl=64 time=278 ms
64 bytes from 10.0.0.2: icmp_seq=507 ttl=64 time=479 ms
64 bytes from 10.0.0.2: icmp_seq=508 ttl=64 time=267 ms
64 bytes from 10.0.0.2: icmp_seq=509 ttl=64 time=270 ms
64 bytes from 10.0.0.2: icmp_seq=510 ttl=64 time=392 ms
64 bytes from 10.0.0.2: icmp_seq=511 ttl=64 time=300 ms
64 bytes from 10.0.0.2: icmp_seq=512 ttl=64 time=276 ms
64 bytes from 10.0.0.2: icmp_seq=513 ttl=64 time=290 ms
64 bytes from 10.0.0.2: icmp_seq=514 ttl=64 time=273 ms
64 bytes from 10.0.0.2: icmp_seq=515 ttl=64 time=431 ms
64 bytes from 10.0.0.2: icmp_seq=516 ttl=64 time=272 ms
64 bytes from 10.0.0.2: icmp_seq=517 ttl=64 time=272 ms
64 bytes from 10.0.0.2: icmp_seq=518 ttl=64 time=881 ms
64 bytes from 10.0.0.2: icmp_seq=519 ttl=64 time=269 ms
64 bytes from 10.0.0.2: icmp_seq=520 ttl=64 time=281 ms

Wollte beim VPN Server DE eine Route anlegen, diese hat jedoch bereits existiert. Werden die evtl. automatisch angelegt?
Ach nochwas, wenn ich hier im OpenWRT device eine Route anlegen will, dann muss ich noch ein Device spezifizieren.

Ich habe hier beim OpenWRT das spezielle dass ich ein Interface eth0 habe mit einer bridge br0 auf wwan0 (WLAN Radio). Und dann noch ein Interface wg0, wie muss ich das ganze zusammenbringen?
Was für ein Routentyp habe ich? Unicast, Multicast etc. ? Im Prinzip scheint ja dann nur noch der "Standort Other" mit der Route zu fehlen, die restlichen Schritte für Standort DE von bluestar habe ich ausgeführt.

Code: Alles auswählen

ip route add 192.168.2.0/24 via 10.0.0.1

in OpenWRT SSH hat schonmal dazu geführt dass ich die Devices in meinem Heimnetz anpingen kann. Jedoch klappt das nicht für die angeschlossenen LAN Geräte, da ist pingen irgendwie auf dem Socket nicht erlaubt.

Habe fast die Vermutung dass das irgendwie mit der bridge Konfiguration ein Problem sein kann.

mat6937 · Beitrag von **mat6937** » 10.03.2020 21:55:38

Knogle hat geschrieben:
10.03.2020 20:38:44
Jedoch klappt das nicht für die angeschlossenen LAN Geräte, da ist pingen irgendwie auf dem Socket nicht erlaubt.

Dann versuch mal mit :

Code: Alles auswählen

The catch-all 0.0.0.0/0 may be specified for matching all IPv4 addresses, ...

bei den "AllowedIPs".

Knogle · Beitrag von **Knogle** » 10.03.2020 23:28:39

mat6937 hat geschrieben:
10.03.2020 21:55:38

Knogle hat geschrieben:
10.03.2020 20:38:44
Jedoch klappt das nicht für die angeschlossenen LAN Geräte, da ist pingen irgendwie auf dem Socket nicht erlaubt.
Dann versuch mal mit :
Code: Alles auswählen
The catch-all 0.0.0.0/0 may be specified for matching all IPv4 addresses, ...
bei den "AllowedIPs".

Das habe ich auch mal probiert, liegt aber irgendwie wohl an dem OpenWRT device.
Im gesamten am LAN angeschlossenen Teil kann ich nicht pingen. Im OpenWRT Forum kriegt man leider keine wirklich Hilfe, weil die meisten da die Fragestellung nicht wirklich verstehen.

ip route show

Code: Alles auswählen

default via 192.168.1.1 dev enp0s25 proto dhcp metric 100 
169.254.0.0/16 dev enp0s25 scope link metric 1000 
192.168.1.0/24 dev enp0s25 proto kernel scope link src 192.168.1.179 metric 100

Von meinem Laptop aus ip addr show

Code: Alles auswählen

chairman@workstation:~$ ip addr show
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: enp0s25: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 54:ee:75:42:0e:b4 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.179/24 brd 192.168.1.255 scope global dynamic noprefixroute enp0s25
       valid_lft 29928sec preferred_lft 29928sec
    inet6 fd1b:c1e2:8857::151/128 scope global dynamic noprefixroute 
       valid_lft 29930sec preferred_lft 29930sec
    inet6 fd1b:c1e2:8857:0:46f9:e91c:7269:4ae4/64 scope global noprefixroute 
       valid_lft forever preferred_lft forever
    inet6 fe80::8c3d:b330:9822:fbdd/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever
3: wlp4s0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether 4c:1d:96:6c:9a:da brd ff:ff:ff:ff:ff:ff

Mal versucht mich selbst anzupingen.

Code: Alles auswählen

chairman@workstation:~$ ping 192.168.1.179
ping: socket: Die Operation ist nicht erlaubt

Das ist schon bitter kurz vor dem Ziel.
Habe fast die Vermutung dass das irgendwie mit der bridge Konfiguration ein Problem sein kann.

mat6937 · Beitrag von **mat6937** » 11.03.2020 00:20:00

Knogle hat geschrieben:
10.03.2020 23:28:39
Code: Alles auswählen
The catch-all 0.0.0.0/0 may be specified for matching all IPv4 addresses, ...
Das habe ich auch mal probiert, liegt aber irgendwie wohl an dem OpenWRT device.
Code: Alles auswählen
ip route add 192.168.2.0/24 via 10.0.0.1

Versuch mal zusätzlich mit:

Code: Alles auswählen

ip route add 192.168.2.0/24 via 10.0.0.1 dev wg0

, wenn Wireguard sämtlichen Traffic durchlassen kann.

Knogle · Beitrag von **Knogle** » 11.03.2020 01:52:47

Danke dir, leider tut es das auch nicht.
Scheinbar gibt es irgendwie Probleme mit der Netzwerkbrücke auf der OpenWRT Seite, und das scheint zumindest laut den ersten Forenbeiträgen nicht so einfach möglich zu sein den Traffic durch das wg Interface zu schicken.
Wird dann wohl eher ein Fall für einen neuen Thread.

Wie soll ich die traceroute Ergebnisse beurteilen vom LAN client aus? Ist da doch ne Verbindung?

Code: Alles auswählen

chairman@workstation:~$ traceroute 10.0.0.2
traceroute to 10.0.0.2 (10.0.0.2), 30 hops max, 60 byte packets
 1  10.0.0.2 (10.0.0.2)  0.350 ms  0.429 ms  0.516 ms
chairman@workstation:~$ traceroute 10.0.0.1
traceroute to 10.0.0.1 (10.0.0.1), 30 hops max, 60 byte packets
 1  OpenWrt.lan (192.168.1.1)  0.401 ms  0.503 ms  0.598 ms
 2  10.0.0.1 (10.0.0.1)  1092.023 ms  1092.321 ms  1093.039 ms
chairman@workstation:~$ traceroute 192.168.2.1
traceroute to 192.168.2.1 (192.168.2.1), 30 hops max, 60 byte packets
 1  OpenWrt.lan (192.168.1.1)  0.430 ms  0.491 ms  0.550 ms
 2  OpenWrt.lan (192.168.1.1)  3142.422 ms !H  3142.460 ms !H  3142.507 ms !H

Habe die Route mal statt auf das eth0 device, auf das WLAN device gebindet, jetzt kommt das.

Code: Alles auswählen

chairman@workstation:~$ traceroute 192.168.2.47
traceroute to 192.168.2.47 (192.168.2.47), 30 hops max, 60 byte packets
 1  OpenWrt.lan (192.168.1.1)  0.408 ms  0.456 ms  0.528 ms
 2  192.168.43.133 (192.168.43.133)  3144.898 ms !H  3144.902 ms !H  3144.975 ms !H

Jetzt mal auf die bridge LAN--> WLAN br0 gebindet.

Code: Alles auswählen

chairman@workstation:~$ traceroute 192.168.2.47
traceroute to 192.168.2.47 (192.168.2.47), 30 hops max, 60 byte packets
 1  OpenWrt.lan (192.168.1.1)  0.370 ms  0.447 ms  0.506 ms
 2  * * 192.168.43.1 (192.168.43.1)  10.383 ms
 3  * * *
 4  * * *
 5  * * *
 6  * * *
 7  * * *
 8  * * *
 9  * * *
10  * * *
11  * * *
12  * * *
13  * * *
14  * * *
15  * * *
16  * * *
17  * * *
18  * * *
19  * * *
20  * * *
21  * * *
22  * * *
23  * * *
24  * * *
25  * * *
26  * * *
27  * * *
28  * * *
29  * * *
30  * * *

Auf wg0 gebindet.

Code: Alles auswählen

traceroute 192.168.2.1
traceroute to 192.168.2.1 (192.168.2.1), 30 hops max, 60 byte packets
 1  OpenWrt.lan (192.168.1.1)  0.321 ms  0.426 ms  0.483 ms
 2  10.0.0.1 (10.0.0.1)  1534.243 ms  1543.417 ms  1544.590 ms
 3  192.168.2.1 (192.168.2.1)  1543.647 ms  1544.013 ms  1545.247 ms

Knogle · Beitrag von **Knogle** » 11.03.2020 02:47:18

Problem soweit gelöst.
Man musste die statische Route auf das Interface "wg0" binden als unicast. Nun klappt das schonmal, und ich kann auf die Adressen innerhalb meines Heimnetzes zugreifen.
Wie mache ich das nun mit dem Telefon?
Da muss man erstmal drauf kommen.. ohne Traceroute echt schwierig.
Die Performance scheint garnicht so schlecht zu sein.

EDIT: Aus irgendeinem Grund hat sich das ganze wieder selbst abgeschossen.
Ist jetzt wieder so.

Code: Alles auswählen

traceroute 192.168.2.47
traceroute to 192.168.2.47 (192.168.2.47), 30 hops max, 60 byte packets
 1  OpenWrt.lan (192.168.1.1)  0.370 ms  0.447 ms  0.506 ms
 2  * * 192.168.43.1 (192.168.43.1)  10.383 ms
 3  * * *
 4  * * *
 5  * * *
 6  * * *
 7  * * *
 8  * * *
 9  * * *
10  * * *
11  * * *
12  * * *
13  * * *
14  * * *
15  * * *
16  * * *
17  * * *
18  * * *
19  * * *
20  * * *
21  * * *
22  * * *
23  * * *
24  * * *
25  * * *
26  * * *
27  * * *
28  * * *
29  * * *
30  * * *

bluestar · Beitrag von **bluestar** » 11.03.2020 07:41:57

Knogle hat geschrieben:
11.03.2020 02:47:18
Wie mache ich das nun mit dem Telefon?

Wie hast du dein Telefon aktuell konfiguriert? DHCP? SIP-Server?

Knogle hat geschrieben:
11.03.2020 02:47:18
Die Performance scheint garnicht so schlecht zu sein.

Einen Vergleich findest du bei Wireguard selbst: https://www.wireguard.com/performance/

debianoli · Beitrag von **debianoli** » 11.03.2020 08:01:58

Wenn im Telefon die Sip-Daten des Anbieters eingetragen sind, braucht man gar nichts machen. Nicht einmal eine VPN Verbindung ist nötig bei NetCologne.

debianforum.de

Devices via VPN ins Lokale Netzwerk brücken

Re: Devices via VPN ins Lokale Netzwerk brücken

Re: Devices via VPN ins Lokale Netzwerk brücken

Re: Devices via VPN ins Lokale Netzwerk brücken

Re: Devices via VPN ins Lokale Netzwerk brücken

Re: Devices via VPN ins Lokale Netzwerk brücken

Re: Devices via VPN ins Lokale Netzwerk brücken

Re: Devices via VPN ins Lokale Netzwerk brücken

Re: Devices via VPN ins Lokale Netzwerk brücken

Re: Devices via VPN ins Lokale Netzwerk brücken

Re: Devices via VPN ins Lokale Netzwerk brücken

Re: Devices via VPN ins Lokale Netzwerk brücken

Re: Devices via VPN ins Lokale Netzwerk brücken

Re: Devices via VPN ins Lokale Netzwerk brücken

Re: Devices via VPN ins Lokale Netzwerk brücken

Re: Devices via VPN ins Lokale Netzwerk brücken

Re: Devices via VPN ins Lokale Netzwerk brücken

Re: Devices via VPN ins Lokale Netzwerk brücken

Re: Devices via VPN ins Lokale Netzwerk brücken

Re: Devices via VPN ins Lokale Netzwerk brücken

Re: Devices via VPN ins Lokale Netzwerk brücken

Re: Devices via VPN ins Lokale Netzwerk brücken

Re: Devices via VPN ins Lokale Netzwerk brücken

Re: Devices via VPN ins Lokale Netzwerk brücken

Re: Devices via VPN ins Lokale Netzwerk brücken

Re: Devices via VPN ins Lokale Netzwerk brücken