[Ungelöst] Debian, Datenverkehr an bestimmte Ports nicht per VPN weiterleiten.

[justinh999]

Hallo
Ich habe bei mir derzeit folgende Situation :
Ich habe zwei Systeme:
System1: Debian 12 Bookworm auf dem aktuellen Stand mit dem VPN Client vpnc
System 2: Eine Fritzbox 7580 mit ihrem intigriertem VPN Client
System 1 ist per VPN dauerhaft mit System 2 verbunden (auf System 1 läuft Home Assistent , über dass ich meine lokalen Smart Home Geräte steuere , die alle mit System 2 verbunden sind , deshalb dass dauerhafte VPN)
Sobald System 1 und 2 verbunden sind , kann ich den Home Assistant auf System1 extern nicht mehr ereichen (ich schätzte ich werde durch den VPN Tunnel auf mein System 2 weitergeleitet wo auf Port 8123(dort läuft der Home Assistant auf System 1) nichts läuft.
Ich kann wenn ich mich in System 2 befinde , system 1 über seine externe IP ereichen , was merkwürdig ist , da dass ja immernoch externen Datenverkehr ist und kein internen und System 1 mich wieder an System 2 weiterleiten müsste.
Ich habe schon versucht mittels :

sudo iptables -t nat -A POSTROUTING -o enp0s6 -p tcp --dport 8123 -j MASQUERADE

Eine Ausnahme im System 1 hinzuzufügen aber ich werde trotzdem noch weitergeleitet .
Hat jemand von euch eventuell einen Tipp , wie ich eine Ausnahme ins System 1 bekomme , sodass Port 8123 nicht über vpn geleitet wird ?


Ergänzung : 31.03 2024
Ich habe auch schon überlegt , ob ich in meinem Router(System B) eine Weiterleitung einstelle , sodass Datenverkehr der an Port 8123 geht automatisch an System A zurückleite , aber nicht über Systems A externe IP sondern über die interne .

System B (die Fritzbox ) weißt VPN Verbindungen eine virtuelle IP Adresse zu ( in meinem Beispiel geht mein DHCP Bereich von 192.168.188.2 bis 192.168.188.150) und meine VPN Verbindung kriegt die Virtuelle IP: 192.168.188.151.

Wenn ich die 192.168.188.151 Aufrufe, während dass VPN verbunden ist , komme ich auf den Server .

Die Fritzbox weigert sich aber eine Portfreigabe auf die 192.168.188.151 zuzulassen, weil dass Gerät nicht in meinem Heimnetztwerk liegt .

Ich müsste also ein Gerät in meinem Heimnetztwerk , auf dass ich dann via Portfreigabe alle Anfragen die an Port 8123 komme weiterleite so konfigurieren , dass sie an die virtuelle IP Adresse des VPN Netztwerkes weitergeleitet werden .

Dass halte ich aber für eine ziemlich sinnlose und uneffiziente Lösung. Vorallem könnte ich dann, wenn ich eh ein Gerät habe dass dauerhaft im Betrieb ist , den home assitent Server auf dem hosten.

 

[horst_lafer]

Hallo!

Einmal die Standard Diagnose ware gut:

ip address
iptables-save
ip route

Danach einen Verbindungsversuch mit ping bzw. traceroute am jeweiligen tun interface loggen via tcpdump:
tcpdump -c 50 -w 0001.pcap -n -i tunX

Unter Umstaenden kann auch ein LOG Target am Ende der INPUT und OUTPUT chain der iptables angebracht werden um zu sehen ob da was nicht durchkommt, sofern -P DROP verwendet wird.
Das kann dann in /var/log/kern.log ausgelesen werden

iptables -A INPUT -m limit --limit 3/min -j LOG --log-prefix "INPUT DROP " --log-level 5
iptables -A OUTPUT -m limit --limit 3/min -j LOG --log-prefix "OUTPUT DROP " --log-level 5

LG

 

[justinh999]

Hallo
Danke für die Antwort !
Alles außer lo , enp0s6 und tun0 kann eigentlich ignoriert werden , da dass alles Adressen von Docker und seinen Conatiner ist (habe in Docker gerade nur Home assist auf Port 8123 laufen)
ip address:

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 noprefixroute
       valid_lft forever preferred_lft forever
2: enp0s6: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP group default qlen 1000
    link/ether 02:00:17:09:fe:e7 brd ff:ff:ff:ff:ff:ff
    inet 10.0.0.190/24 brd 10.0.0.255 scope global dynamic noprefixroute enp0s6
       valid_lft 86022sec preferred_lft 86022sec
    inet6 fe80::71fb:6925:f5fb:2f8f/64 scope link noprefixroute
       valid_lft forever preferred_lft forever
3: docker0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
    link/ether 02:42:d4:65:f9:b2 brd ff:ff:ff:ff:ff:ff
    inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0
       valid_lft forever preferred_lft forever
    inet6 fe80::42:d4ff:fe65:f9b2/64 scope link
       valid_lft forever preferred_lft forever
4: hassio: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
    link/ether 02:42:70:db:57:7c brd ff:ff:ff:ff:ff:ff
    inet 172.30.32.1/23 brd 172.30.33.255 scope global hassio
       valid_lft forever preferred_lft forever
    inet6 fe80::42:70ff:fedb:577c/64 scope link
       valid_lft forever preferred_lft forever
6: vethbe10536@if5: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master hassio state UP group default
    link/ether 42:2f:e1:96:ce:99 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet6 fe80::402f:e1ff:fe96:ce99/64 scope link
       valid_lft forever preferred_lft forever
8: veth073d301@if7: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master docker0 state UP group default
    link/ether 46:93:d4:15:b9:3b brd ff:ff:ff:ff:ff:ff link-netnsid 1
    inet6 fe80::4493:d4ff:fe15:b93b/64 scope link
       valid_lft forever preferred_lft forever
10: veth22e173d@if9: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master hassio state UP group default
    link/ether 5e:ce:17:bd:50:ab brd ff:ff:ff:ff:ff:ff link-netnsid 1
    inet6 fe80::5cce:17ff:febd:50ab/64 scope link
       valid_lft forever preferred_lft forever
12: vethdc775fe@if11: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master hassio state UP group default
    link/ether fe:67:ef:cb:b1:d4 brd ff:ff:ff:ff:ff:ff link-netnsid 2
    inet6 fe80::fc67:efff:fecb:b1d4/64 scope link
       valid_lft forever preferred_lft forever
14: veth7584d5d@if13: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master hassio state UP group default
    link/ether 5a:bc:7e:cc:ae:f2 brd ff:ff:ff:ff:ff:ff link-netnsid 3
    inet6 fe80::58bc:7eff:fecc:aef2/64 scope link
       valid_lft forever preferred_lft forever
16: veth07de3ca@if15: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master hassio state UP group default
    link/ether 86:f3:0d:ea:9c:7b brd ff:ff:ff:ff:ff:ff link-netnsid 4
    inet6 fe80::84f3:dff:feea:9c7b/64 scope link
       valid_lft forever preferred_lft forever
17: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 8912 qdisc fq_codel state UNKNOWN group default qlen 500
    link/none
    inet 192.168.188.253/32 scope global tun0
       valid_lft forever preferred_lft forever
    inet6 fe80::e7b5:d3f7:b632:eaf9/64 scope link stable-privacy
       valid_lft forever preferred_lft forever

Wenn dass VPN deaktiviert wird , verschwindet die Nummer 17 einfach ( was ja logisch ist) , sonst verändert sich nichts (warum sollte es auch,dass VPN ändert ja nichts an den anderen Verbindungen)
iptables-save:

# Generated by iptables-save v1.8.9 (nf_tables) on Tue Apr  2 14:55:02 2024
*filter
:INPUT ACCEPT [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]
:DOCKER - [0:0]
:DOCKER-ISOLATION-STAGE-1 - [0:0]
:DOCKER-ISOLATION-STAGE-2 - [0:0]
:DOCKER-USER - [0:0]
-A FORWARD -j DOCKER-USER
-A FORWARD -j DOCKER-ISOLATION-STAGE-1
-A FORWARD -o docker0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -o docker0 -j DOCKER
-A FORWARD -i docker0 ! -o docker0 -j ACCEPT
-A FORWARD -i docker0 -o docker0 -j ACCEPT
-A FORWARD -o hassio -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -o hassio -j DOCKER
-A FORWARD -i hassio ! -o hassio -j ACCEPT
-A FORWARD -i hassio -o hassio -j ACCEPT
-A DOCKER -d 172.30.32.6/32 ! -i hassio -o hassio -p tcp -m tcp --dport 80 -j ACCEPT
-A DOCKER-ISOLATION-STAGE-1 -i docker0 ! -o docker0 -j DOCKER-ISOLATION-STAGE-2
-A DOCKER-ISOLATION-STAGE-1 -i hassio ! -o hassio -j DOCKER-ISOLATION-STAGE-2
-A DOCKER-ISOLATION-STAGE-1 -j RETURN
-A DOCKER-ISOLATION-STAGE-2 -o docker0 -j DROP
-A DOCKER-ISOLATION-STAGE-2 -o hassio -j DROP
-A DOCKER-ISOLATION-STAGE-2 -j RETURN
-A DOCKER-USER -j RETURN
COMMIT
# Completed on Tue Apr  2 14:55:02 2024
# Generated by iptables-save v1.8.9 (nf_tables) on Tue Apr  2 14:55:02 2024
*nat
:PREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
:DOCKER - [0:0]
-A PREROUTING -m addrtype --dst-type LOCAL -j DOCKER
-A OUTPUT ! -d 127.0.0.0/8 -m addrtype --dst-type LOCAL -j DOCKER
-A POSTROUTING -s 172.17.0.0/16 ! -o docker0 -j MASQUERADE
-A POSTROUTING -s 172.30.32.0/23 ! -o hassio -j MASQUERADE
-A POSTROUTING -s 172.30.32.6/32 -d 172.30.32.6/32 -p tcp -m tcp --dport 80 -j MASQUERADE
-A POSTROUTING -o enp0s6 -p tcp -m tcp --dport 8123 -j MASQUERADE
-A DOCKER -i docker0 -j RETURN
-A DOCKER -i hassio -j RETURN
-A DOCKER ! -i hassio -p tcp -m tcp --dport 4357 -j DNAT --to-destination 172.30.32.6:80
COMMIT
# Completed on Tue Apr  2 14:55:02 2024

ip route(aktiviertes vpn):

default dev tun0 scope link
default via 10.0.0.1 dev enp0s6 proto dhcp src 10.0.0.190 metric 100
10.0.0.0/24 dev enp0s6 proto kernel scope link src 10.0.0.190 metric 100
169.254.0.0/16 dev enp0s6 proto dhcp scope link src 10.0.0.190 metric 100
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1
172.30.32.0/23 dev hassio proto kernel scope link src 172.30.32.1
217.87.185.190 via 10.0.0.1 dev enp0s6 src 10.0.0.190 metric 100

ip route (deaktiviertes vpn)

default via 10.0.0.1 dev enp0s6 proto dhcp src 10.0.0.190 metric 100
10.0.0.0/24 dev enp0s6 proto kernel scope link src 10.0.0.190 metric 100
169.254.0.0/16 dev enp0s6 proto dhcp scope link src 10.0.0.190 metric 100
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1
172.30.32.0/23 dev hassio proto kernel scope link src 172.30.32.1

Die IP Routen spiegeln genau den Zustand wieder den ich habe
VPN Aktiv -> gesamter Datenverkehr über tun0 (also alles übers vpn außer die Packete die spezifisch geroutet werden )
VPN Inaktiv -> gesamter Datenvekehr über enp0s6(wenn nicht spziele geroutet) .

Danach einen Verbindungsversuch mit ping bzw. traceroute am jeweiligen tun interface loggen via tcpdump:
tcpdump -c 50 -w 0001.pcap -n -i tunX

In meinem Fall wäre dass tun0 .
Die Packete scheinen aufjendefall durchzukommen und es wird auch versucht eine Antwort zu senden:

 1   0.000000   [interne iP Adresse System A] → [öffentliche Ip meines Handys im Mobilfunknetzt] ICMP 84 Echo (ping) reply    id=0x0541, seq=32376/30846, ttl=64
 2   4.009618   [interne IP Adresse System A] → [öffentliche Ip meines Handys im Mobilfunknetzt] ICMP 84 Echo (ping) reply    id=0x0542, seq=49225/18880, ttl=64
 3   8.032340   [interne IP Adresse System A] → [öffentliche Ip meines Handys im Mobilfunknetzt] ICMP 84 Echo (ping) reply    id=0x0543, seq=51271/18376, ttl=64

Die Ping Packete kommen auf tun0 und enp0s6 durch(beides sind die gleichen anfragen)(von extern(Handy mobilfunknetzt).
Wenn ich jetzt aus dem System B System die externe IP von System A anpinge , landet dass Packet nur bei enp0s6 und nicht bei tun0 also genau den Zustand , den dass externe Packet ( aus dem Mobilfunknetzt von meinem Handy ) auch haben sollte .

iptables -A INPUT -m limit --limit 3/min -j LOG --log-prefix "INPUT DROP " --log-level 5
iptables -A OUTPUT -m limit --limit 3/min -j LOG --log-prefix "OUTPUT DROP " --log-level 5

Ich weiß nicht ob die Ergebnisse dieses Dumps bei mir eventuell irgendwo anders hingeschrieben werden aber im /var/log/ wurde kein Kern.log erstellt .
LG

 

[horst_lafer]

iptables -A INPUT -m limit --limit 3/min -j LOG --log-prefix "INPUT DROP " --log-level 5
iptables -A OUTPUT -m limit --limit 3/min -j LOG --log-prefix "OUTPUT DROP " --log-level 5

Ich weiß nicht ob die Ergebnisse dieses Dumps bei mir eventuell irgendwo anders hingeschrieben werden aber im /var/log/ wurde kein Kern.log erstellt .
LG

Hi, ja das sieht erstmal in Ordnung aus. Ich nehme an dass dein VPN Server eine PUSH control message mit redirect-gateway def1 sendet bzw. die Routen uebernommen werden, was der Grund ist warum alles automatisch ueber das tun0 interface ohne weitere iptables bzgl. forwarding laeuft.

Da faellt mir dann wirklich nur noch die Firewall ein, und die Moeglichkeit dass hier Pakete keine passende Regel finden bzw. gedropped werden.

Das Paket rsyslog muss intstalliert sein damit /var/log/kern.log generiert wird, sorry das hatte ich vergessen zu erwaehnen.

Ich sehe dass deine INPUT und OUTPUT chain Default Policy ACCEPT ist, das heisst da geht sowieso alles durch.
Bring stattdessen an der FORWARD chain eine LOG Regel an, und dann noch im nat table und den Docker chains.

iptables -A FORWARD -m limit --limit 3/min -j LOG --log-prefix "FORWARD DROP " --log-level 5
iptables -A POSTROUTING -m limit --limit 3/min -j LOG --log-prefix "POST SKIP " --log-level 5

Zuletzt noch eine kleine Warnung, die derzeitigen Regeln erlauben Docker einen moeglichen Zugriff auf dein enp0s6 interface, sofern das VPN die Verbindung verliert und tun0 sich verabschiedet. Falls du keine zusaetzliche Firewall verwendest gaebe es also keine Leak Protection und dein VPN Traffic kann beim Ausfall direkt ueber das Haupt interface klar laufen.
Einen Kill-Switch kriegst du ganz einfach hin indem die Docker Regeln spezifisch an -i / -o tun0 angepasst werden.