[gelöst] Routing Problem

[schorsch_76]

Hallo dfde,

gegeben sei folgende Netzstruktur.

Code: Alles auswählen

      +---------+     +----------+    +----------+
      | HomeLAN +-----+ Internet +----+  Remote  |
      | Router  |     |          |    |  Router  |
      +---------+     +----------+    +------+---+
           +          +----------+           |
           |          |          |           |
           |      +---+ VPN      +------+    |
           |      |   | 150      |      |    |
           |160   |   +----------+      |    |
           |      |                     |    |
           |      |                     |2   |
           |      |                   +-+----+----+
     +-----+----+ |                   |tun0  wlan0|
     |          | |                   +-----------+
     |19     11 | |1                  |           |
+----+--+  +------+---+               |Logger     |
|   eth0|  |eth0  tun0|               |           |
+-------+  +----------+               +-----------+
|       |  |          |               |    eth0 1 |
|Rechner|  | Datenbank|               +-----+-----+
|       |  | VPN      |                     |
|       |  |          |                     |178
|       |  |          |          +----------++
|       |  |          |          |           |
+-------+  +----------+     +----+---+   +---+----+
                            |D1   23 |   |D2    24|
                            +--------+   +--------+

Der Logger baut via VPN eine Verbindung zum VPNServer/Datenbankserver auf. Die Verbindung Logger/Remote ist die "wackelige" WLAN Verbindung von der ich kürzlich [1] gesprochen hatte.

Der HomeLAN Router hat für das Subnetz 150/24 und 178/24 einen Redirect auf den VPN Server 160.11. Der VPNServer hat die Route für das 178/24 Netz via 150.2. Er macht für 150.0/24 ein Masqerading auf eth0.

Der Rechner 160.19 im Heimnetz kann einen Ping und SSH auf den Logger (150.2) machen. Aber er kann die Geräte D1/D2 nicht anpingen. Vom VPNServer auf D1/D2 geht auch kein ping. Vom Logger aus kann ein Ping auf den Rechner 160.19 und den HomeLAN Router gemacht werden. Vom Logger aus kann D1 und D2 angepingt werden,

net.ip4v_forwarding=1 ist auf dem VPNServer und dem Logger aktiv. Braucht der VPNServer ein SNAT? Warum geht es von Logger Richtung VPN aber nicht in der anderen Richtung?



Alle Geräte nutzen Debian Bookworm/amd64 (ausser die Router).

[1] viewtopic.php?t=187401

[MSfree]

Welche VPN-Software setzt du ein?

[schorsch_76]

openvpn in der Konfiguration aus dem Debian Wiki [1] mit CA.

[1] https://wiki.debian.org/OpenVPN

EDIT: Je mehr ich darüber nachdenke: Brauch ich das Masqerading? Reicht nicht die default Route?

[MSfree]

Mit tun0 hast du bei OpenVPN bereits ein geroutetes VPN, das keinerlei NAT, SNAT oder DNAT benötigt, wenn man es richtig aussetzt.

server.conf

Code: Alles auswählen

port 1194
proto udp
dev tun0

;tls-server
ca /etc/openvpn/ca.crt
cert /etc/openvpn/server.crt
key /etc/openvpn/server.key  # This file should be kept secret
dh /etc/openvpn/dh4096.pem
tls-auth /etc/openvpn/ta.key 0 # This file is secret

server 10.11.12.0 255.255.255.0
ifconfig-pool-persist ipp.txt
client-config-dir /etc/openvpn/clientconfigs
route 192.168.remote.0 255.255.255.0
push "route 192.168.local.0 255.255.255.0"
client-to-client

keepalive 5 120

;cipher BF-CBC        # Blowfish (default)
cipher AES-256-CBC   # AES
;cipher DES-EDE3-CBC  # Triple-DES

max-clients 20
user nobody
group nogroup
persist-key
persist-tun
persist-remote-ip

status openvpn-status.log
verb 2

fragment 750

client.conf

Code: Alles auswählen

client
dev tun
proto udp
remote host.domain.tld 1194

resolv-retry 5
nobind
user nobody
group nogroup

persist-key
persist-tun

ca /etc/openvpn/ca.crt
cert /etc/openvpn/client.crt
key /etc/openvpn/client.key
tls-auth /etc/openvpn/ta.key 1

cipher AES-256-CBC

keepalive 30 120
verb 5

fragment 750
mssfix 750

Ich habe hier dem VPN das Subnetz 10.11.12.0 vergeben. Gleichzetig lege ich Routen an, so daß das entfernte Netz 192.168.remote.0 über des 10.11.12.0 Netz geroutet wird. Dem Entfernten Client sage ich per push "route 192.168.local.0 255.255.255.0", daß der Client über das 10.11.12.xx-Netz, das Netz mit der IP 192.168.local.0 erreicht.

Die fragment Geschichte war bei einer Installation zwischen zwei DSL-Anschlüssen nötig, um Hänger zu vermeiden. Der Wert ist emperimentell ermittelt worden.

[schorsch_76]

Das Masqerading war eher aus "Gewohnheit" drin ... das werde ich heute Abend mal deaktivieren und schauen obs das war.

Es kam auch häufiger die Meldung TTL exceeded (oder so ähnlich) wenn ich von 160.19 auf 178.23 pingen wollte. Könnte sein das das Ping Paket dann in eine "Schleife" kam da auch die 150.1 ja in 150.0/24 enthalten ist...

[mludwig]

Der HomeLAN Router hat für das Subnetz 150/24 und 178/24 einen Redirect auf den VPN Server 160.11. Der VPNServer hat die Route für das 178/24 Netz via 150.2. Er macht für 150.0/24 ein Masqerading auf eth0.

Das sollte wohl ein Masquerade auf tun0 sein? Edit: wenn das auf eth0 war, müsste auch der Logger noch die Route für das Netz 160 bekommen. Wenn MASQ wegfällt sowieso.

Ansonsten fehlt wohl eine Rückroute, damit D1/D2 zurück über den VPN gehen. D. h. der Remote-Router sollte (mit MASQ) wenigstens das Transfernetz 150 kennen und per Route zum Logger schicken, ohne MASQ auch das Home Netz 160.

[schorsch_76]

Das Masqerading ist auf jeden fall unnötig.

Auf dem Logger sieht es so aus:

Code: Alles auswählen

sysctl net.ipv4.ip_forward
net.ipv4.ip_forward = 1

ping 192.168.160.19
PING 192.168.160.19 (192.168.160.19) 56(84) bytes of data.
64 bytes from 192.168.160.19: icmp_seq=1 ttl=63 time=11.8 ms
^C

Code: Alles auswählen

ip r
default via 192.168.2.1 dev wlan0 proto dhcp src 192.168.2.122 metric 601 
192.168.2.0/24 dev wlan0 proto kernel scope link src 192.168.2.122 metric 601 
192.168.150.0/24 dev tun0 proto kernel scope link src 192.168.150.2 
192.168.160.0/24 via 192.168.150.1 dev tun0 
192.168.178.0/24 dev eth0 proto kernel scope link src 192.168.178.1 metric 100 
192.168.210.0/24 via 192.168.150.1 dev tun0

Auf dem VPNServer

Code: Alles auswählen

sysctl net.ipv4.ip_forward
net.ipv4.ip_forward = 1

ip r
default via 192.168.160.1 dev eth0 proto dhcp src 192.168.160.84 metric 202 mtu 1500 
192.168.150.0/24 dev tun0 proto kernel scope link src 192.168.150.1 
192.168.160.0/24 dev eth0 proto dhcp scope link src 192.168.160.84 metric 202 mtu 1500 
192.168.178.0/24 via 192.168.150.2 dev tun0 
192.168.210.0/24 dev br0 proto dhcp scope link src 192.168.210.73 metric 204 

Code: Alles auswählen

ping -c 1 -W2 192.168.178.1
PING 192.168.178.1 (192.168.178.1) 56(84) bytes of data.

--- 192.168.178.1 ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms

Code: Alles auswählen

ping -c 1 -W2 192.168.150.2
PING 192.168.150.2 (192.168.150.2) 56(84) bytes of data.
64 bytes from 192.168.150.2: icmp_seq=1 ttl=64 time=66.2 ms

--- 192.168.150.2 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 66.188/66.188/66.188/0.000 ms

[schorsch_76]

Ich denke es ist eine tun Beschränkung vs tap. Werde einen Reverse Proxy auf dem Logger installieren dann ist das Problem gelöst.

[mat6937]

Code: Alles auswählen

ping -c 1 -W2 192.168.178.1
PING 192.168.178.1 (192.168.178.1) 56(84) bytes of data.

--- 192.168.178.1 ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms

Wie sind auf dem Logger die Ausgaben von:

Code: Alles auswählen

iptables -nvx -L -t nat
ip r g 192.168.178.1

?

[schorsch_76]

Wie sind auf dem Logger die Ausgaben von:

Code: Alles auswählen

iptables -nvx -L -t nat
ip r g 192.168.178.1

?

Code: Alles auswählen

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      

Code: Alles auswählen

ip r g 192.168.178.1
local 192.168.178.1 dev lo src 192.168.178.1 uid 0 
    cache <local> 

[mat6937]

Code: Alles auswählen

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

Versuch mal auch mit MASQUEARDE-Regeln (nicht das klassische source-NAT) für das WAN- und für das VPN-Interface.

Code: Alles auswählen

ip r g 192.168.178.1
local 192.168.178.1 dev lo src 192.168.178.1 uid 0 
    cache <local> 

Diese definierte Route via lo-Interface ist nicht OK. Versuch mit einer definierten Route ins Subnetz 192.168.178.0/24 via VPN-Interface.

[schorsch_76]

Das 192.168,178.0/24 Netz ist lokal an eth0 angeschlossen. Diese Route kommt vom network-manager der für dieses Interface eine statische Adresse bekommen hat. Momentan komm ich gerade nicht auf das Gerät weil die Verbindung wieder mal down ist... ... Der Logger schreibt seine Werte deshalb in eine lokale DB.

Aus meinem Backup lese ist das folgende aus:

Code: Alles auswählen

sudo cat etc/NetworkManager/system-connections/Ethernet.nmconnection 
[connection]
id=Ethernet
uuid=f0150d09-442f-382d-ac38-c20edb7ca4e8
type=ethernet
autoconnect-priority=-999
interface-name=eth0
timestamp=1689963989

[ethernet]

[ipv4]
address1=192.168.178.1/24
may-fail=false
method=manual

[ipv6]
addr-gen-mode=default
ignore-auto-dns=true
ignore-auto-routes=true
method=ignore
never-default=true

[proxy]

Edit: Zur Verdeutlichung der "Qualität" der Verbindung hab ich mal einen Ping vom VPNServer auf den Logger gemacht.

Code: Alles auswählen

--- 192.168.150.2 ping statistics ---
293 packets transmitted, 109 received, 62.7986% packet loss, time 295265ms
rtt min/avg/max/mdev = 11.665/128.140/573.081/105.032 ms

Durch den automatischen Reconnect und die lokale CacheDB gehen trotzdem keine Werte verloren.