☰

Martian-Pakete nach der Verbindung mit dem OpenVPN-Client

tag-icon • tag-icon iptables routing openvpn
Martian-Pakete nach der Verbindung mit dem OpenVPN-Client

Hintergrund:

Ich verbinde mich über einen OpenVPN-Client (v2.4.4) von der Befehlszeile aus hinter einem Heimrouter, auf dem OpenWRT läuft, mit einem Server.

In letzter Zeit habe ich Folgendes in meinem Syslog gesehen:

Aug  8 17:16:28 Deluxe kernel: [12972.603549] IPv4: martian source 192.168.1.100 from 34.210.182.212, on dev eno1
Aug  8 17:16:28 Deluxe kernel: [12972.603572] ll header: 00000000: d0 17 c2 ac 64 4b c4 e9 84 48 79 32 08 00        ....dK...Hy2..
Aug  8 17:16:28 Deluxe kernel: [12972.910801] IPv4: martian source 192.168.1.100 from 34.210.182.212, on dev eno1
Aug  8 17:16:28 Deluxe kernel: [12972.910822] ll header: 00000000: d0 17 c2 ac 64 4b c4 e9 84 48 79 32 08 00        ....dK...Hy2..
Aug  8 17:16:28 Deluxe kernel: [12973.230932] IPv4: martian source 192.168.1.100 from 34.210.182.212, on dev eno1
Aug  8 17:16:28 Deluxe kernel: [12973.230953] ll header: 00000000: d0 17 c2 ac 64 4b c4 e9 84 48 79 32 08 00        ....dK...Hy2..

Die erste MAC-Adresse in der ll headerZeile ist meine Netzwerkkarte, die zweite ist eine Ethernet-Schnittstelle am Router.

Meine Routentabelle sieht vor der Verbindung folgendermaßen aus:

[2020-08-08 ☱ 18:35 ☴]$ route -n
Kernel IP routing table                                                        
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface  
0.0.0.0         192.168.1.1     0.0.0.0         UG    0      0        0 eno1   
192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 eno1

Und so sieht es kurz nach dem Verbinden aus:

[2020-08-08 ☱ 18:35 ☴]$ route -n                                                
Kernel IP routing table                                                             
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface       
0.0.0.0         10.25.40.1      128.0.0.0       UG    0      0        0 tun0        
0.0.0.0         192.168.1.1     0.0.0.0         UG    0      0        0 eno1        
10.25.40.0      0.0.0.0         255.255.255.0   U     0      0        0 tun0        
128.0.0.0       10.25.40.1      128.0.0.0       UG    0      0        0 tun0        
185.228.19.148  192.168.1.1     255.255.255.255 UGH   0      0        0 eno1        
192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 eno1

Die Host-IP von unten ist das VPN-Gateway. Der tun0Adapter ist folgendermaßen konfiguriert:inet 10.25.40.244 netmask 255.255.255.0 destination 10.25.40.244

Nach drei bis fünf Minuten lässt der Marsverkehr nach und erscheint nur noch selten.

Ich habe die Verbindung openvpnohne installierten Router getestet (direkte Verbindung zu meinem Modem) und das Gleiche passiert.

Ich lehne mich hier weit aus dem Fenster, aber es scheint, dass bei einer abrupten Änderung des Routings (wie es bei einer benutzerinitiierten VPN-Verbindung der Fall ist) bestehende/verwandte Verbindungen bestehen bleiben und als ungültig gelöscht werden. Mit der Zeit sterben diese Verbindungen ab.

Fragen:

  1. Ist mein Verständnis der Ursache der Marspakete richtig?
  2. Wie kann ich das Verlieren dieser Pakete verhindern? Könnte ich beispielsweise die - natoder mangle-Tabellen verwenden, iptablesum diese Pakete an die tunSchnittstelle zu leiten?

Antwort1

  1. Dein Verständnis ist korrekt.
  2. In meinem Fall habe ich einfach aufgehört, solche Pakete zu protokollieren. Selbst wenn es ein Angriff ist, wird er nicht funktionieren, weil das Routing verhindern würde, dass er jemals erfolgreich ist:
net.ipv4.conf.all.log_martians = 0

verwandte Informationen