Raspberrypi.gateway

Alternativer Internet-Zugang

• Ich konfiguriere einen Raspberry Pi (Trixie) als Gateway so dass ich einen alternativen Internet-Zugang nutzen kann
• Das Gateway erhalte ja ich automatisch auf einem Windows-System per DHCP - kann aber das Gateway dann temporär wechseln:

• 192.168.178.1 ist das Standard-Gateway via DHCP, so ist es nach dem Einschalten
• 192.168.178.50 ist mein Raspberry Pi, der dann einen ganz anderen Internet-Zugang zur Verfügung stellt

• Ein Raspberry muss dann 2 Netzwerkschnittstellen haben
  • einen im aktuellen Netz z.B. "wlan0"
  • einen der direkt Client des alternativen Internetzugangs ist z.B. "eth0"
• So kann sich der Raspberry Pi mit einem WLAN verbindet
  • dieses ist ein durch ein Handy aufgespannter HotSpot "wlan0"
  • oder direkt am Arris Modem eines Vodafone Kabel Anschlusses "eth0" (also vertauschte Rollen, LAN am Modem, WLAN in deinem Netz)
• Das Gateway muss immer vom Soll- Internetzugang gesetzt werden
• Der Gateway Eintrag vom lokalen Netz muss ignoriert oder gelöscht werden!

im lokalen-Device (dein Netz)

Mit nmtui das setzen des Gateway rausnehmen

im Internet-Zugang (dein alternativer Internet-Zugang)

meine "and-firewall.sh"

#!/bin/bash

#
# erst mal die Tabellen leeren
#
iptables -F
iptables -X
iptables -t nat -F
iptables -t nat -X
iptables -t mangle -F
iptables -t mangle -X

#
echo 1 > /proc/sys/net/ipv4/ip_forward

DEV_LOC=eth0
DEV_EXT=eth1 

iptables -t nat -A POSTROUTING -o $DEV_EXT -j MASQUERADE

#
# Show what you set
iptables -t nat -L -n -v

starten der and-firewall mit einem systemd service

#
# /etc/systemd/system/and-firewall.service
#

[Unit]
Description=route like a gateway
Requires=network-online.target
After=network-online.target

[Service]
Type=oneshot
WorkingDirectory=/root
ExecStart=/root/and-firewall.sh

[Install]
WantedBy=multi-user.target

Wenn man einen DHCP-Server betreibt

# /etc/dhcp/
#

...

  host pi3x02 {
   option host-name "pi3x02";
   hardware ethernet b8:27:eb:bd:79:cc;
   fixed-address pi3x02;
   option routers false;
  }

...

#

• dadurch ist pi3x02 ein normaler DHCP Client, er bekommt jedoch keine Standard-Route, gut in diesem Fall
• im Notfall die default route löschen ip route del default

#!/bin/bash

#
# erst mal die Tabellen leeren
#
iptables -F
iptables -X
iptables -t nat -F
iptables -t nat -X
iptables -t mangle -F
iptables -t mangle -X

#
# System für TCP-Manipulationen öffnen
#
echo "1" > /proc/sys/net/ipv4/ip_forward

#
# Fritz!Box zugänglich machen
#
iptables -t nat -A PREROUTING -i wlan0 -p tcp --dport 443 -j DNAT --to-destination 192.168.178.1:443
iptables -t nat -A PREROUTING -i wlan0 -p tcp --dport 80 -j DNAT --to-destination 192.168.178.1:80
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

#
# System als Gateway befähigen
#
iptables -t nat -A POSTROUTING -o wlan0 -j MASQUERADE

Fritz!Box

Oberfläche

• Ziel ist es, die Fritz!Box, die am eth0 Interface hängt sichtbar zu machen
• Der Raspi ist über WLAN in unser Netz angebunden

echo "1" > /proc/sys/net/ipv4/ip_forward
iptables -t nat -A PREROUTING -i wlan0 -p tcp --dport 443 -j DNAT --to-destination 192.168.178.1:443
iptables -t nat -A PREROUTING -i wlan0 -p tcp --dport 80 -j DNAT --to-destination 192.168.178.1:80
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

• Voraussetzung sind ordentliche Routen, dies wird erreicht dass der DHCPD Server an eth0 keine Standard-Route sendet. Stichwort "options route false"

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         fritz.box       0.0.0.0         UG    202    0        0 eth0
192.168.115.0   0.0.0.0         255.255.255.0   U     303    0        0 wlan0
192.168.178.0   0.0.0.0         255.255.255.0   U     202    0        0 eth0

Freigaben

In 2 verschiedenen Netzen

• Durch Erhöhen/Vermindern der Metric kann die Benutzung einer anderen Verbindung EIN oder AUS geschaltet werden

nmcli connection modify 'Wired connection 2' ipv4.route-metric 50
nmcli connection modify 'Wired connection 2' ipv6.route-metric 50

VLAN für verschiedene Netze (auf einer Leitung)

• Wegen einer Störung habe ich mich entschieden einen alternativen Internet-Zugang anzuschaffen
• So habe ich einen DSL-Zugang (Fritz!BOX 7490) einen Kabel-Zugang (Vodafone-Arris-Modem) und eine herumliegende Fritz!BOX 7590
• Den WLAN-Zugang des Arris-Modems schalte ich ab
• Die 2 Fritz!Boxen spannen jeweils ein eigenes Mesh-WLAN-Netzwerk auf, der WAN-Eingang der 7590 wird vom Arris-Modem gespeist - so hat jedes Mesh einen Internet-Zugang
• Die Mesh Repeater sind zu einem Großteil über LAN an den Mesh-Master angebunden
• Es gibt 3 LAN-Netzwerke, 2x Fritz!BOX und 1x Arris-Modem
• Die verschiedenen Wohnungen sind nur über ein Netzwerkkabel angeschlossen. Um an jedem Netzwerk-Punkt alle 3 LAN Netze abgreifen zu können verwende ich die VLAN Technologie
• Die Uplinks (dafür verwende ich die rechten/hohen Ports der Switche also Port 6-8) sind alle Tagged und transportieren alle 3 Netze
• Administriert werden die Switche über den Port 1, da ist immer VLAN 1 ungetagged, so sperre ich mich nie aus

• Will man die 3 TL-SG108E weiterhin über Port1 administrieren, so muss ...
  • ... Port 1 (weiterhin) den PVID=1 haben
  • ... Port 1 untagged und exclusiv dem VLAN 1 angehören

VLANs erstellen

Software

• Ich will dass ein Raspi mit einer Schnittstelle (eth0) in allen 3 Netzwerken ist
• Dazu sollen über DHCP 3 Netzwerkadressen und 3 Routen und 3 DNS gezogen werden
• Dazu schliesse ich den Raspi-eth0 an einen Tagged-Port eines Switches an (Port mit allen Netzen VLAN Id=1 / VLAN Id=2 / VLAN Id=3)
• Auf einem Raspberry Pi mit (Trixie) verwende ich den Netzwerkmanager
• Fraglich: Muss man das Paket apt install vlan installieren?
• Fraglich: Muss man das Kernel Modul modprobe 8021q installieren?

#
# eth0 vorbereiten
#
nmtui
IPv4 Configuration <Disabled>
IPv6 Configuration <Disabled>
[ ] Automatically Connect
[ ] Awailable to all users



#
# 3 vlan Adapter erstellen
#
nmcli con add type vlan con-name "vlan1-conn" dev eth0 id 1
nmcli con add type vlan con-name "vlan2-conn" dev eth0 id 2
nmcli con add type vlan con-name "vlan3-conn" dev eth0 id 3

#
# ip r
default via 192.168.0.1 dev eth1 proto dhcp src 192.168.0.236 metric 100
default via 192.168.178.1 dev eth0.1 proto dhcp src 192.168.178.50 metric 402
default via 192.168.0.1 dev eth0.2 proto dhcp src 192.168.0.15 metric 403
default via 192.168.115.8 dev eth0.3 proto dhcp src 192.168.115.62 metric 404
192.168.0.0/24 dev eth1 proto kernel scope link src 192.168.0.236 metric 100
192.168.0.0/24 dev eth0.2 proto kernel scope link src 192.168.0.15 metric 403
192.168.115.0/24 dev eth0.3 proto kernel scope link src 192.168.115.62 metric 404
192.168.115.0/24 dev wlan0 proto kernel scope link src 192.168.115.18 metric 601
192.168.178.0/24 dev eth0.1 proto kernel scope link src 192.168.178.50 metric 402
192.168.178.0/24 dev wlan2 proto kernel scope link src 192.168.178.70 metric 600

Hardware

• Über die Administration der beteiligten Switche werden die VLANs abgebildet
• Die beteiligten Repeater und Router merken davon nichts und müssen nicht für VLANs vorbereitet werden
• Die 3 VLANs sind für Endgeräte völlig getrennt, Teilnehmer eines Netzes können die anderen 2 Netze nicht sehen

Switch Heizraum

Switch Keller

Switch DG

Switch W3

Diagnose

# kann der Kernel das?
modinfo 8021q

#
tcpdump -nnei eth0 -vvv

#
# mal prüfen was auf dem device so los ist, das ist sehr hilfreich
# vlan rot markiert
tcpdump -nnei eth0 -vvv | grep --color " vlan "

vbkraichgau.de ERR_CONNECTION_TIMED_OUT

• Ich habe einen 1und1 (1&1, eins und eins) DSL-Anschluss (DS-Lite) und ab und zu ganztägige Timeouts beim Verbindungsversuch zu vbkraichgau.de (Homepage und Login).
• Im lokalen WLAN angemeldete Handys: Es funktioniert die "VR Banking App" dann auch nicht
• Alle anderen https://, http:// Seiten im Internet funktionieren - der Anschluss ist ansonsten störungsfrei

Spekulation der Adruvia über die Ursache

• Die Ursache würde am Internet-Anbieter 1und1 liegen
• DS-Lite wäre kein richtiger Internetanschluss man bräuchte einen Anschluss mit IP V4 Adresse
• IP V6 ist zu gering verbreitet deshalb wird es nicht angeboten und führt zu Problemen in Zusammenarbeit mit IP V4

Dazu meine Stellungnahme

• Nein, es liegt nicht am Provider 1 und 1
• Nein, DS-Lite hat keine Nachteile bei http://, https://
  • DS-Lite vergibt eine IP V4 Adresse UND eine IP V6 Adresse - Immer beide!
  • Auf IP V4 Seite gibt es Einschränkungen bei der Erreichbarkeit aus dem Internet (Rückkanal) was beim Surfen jedoch keine Rolle spielt
  • Die zugeteilte IP V4 Adresse ist NICHT auf einen aktuell aktiven Internetzugang beschränkt
  • Der Rückkanal ist nur auf IP V6 Seite unbeschränkt
  • Die Exklusivität (1 Zugang:1 Adresse) ist nur auf der IP V6 Seite gegeben, von einer 1:1 Beziehung kann bei V4 NICHT ausgegangen werden
• IP V6 als alternativen Zugang anzubieten führt seit Jahren zu keiner Störung im IP V4 Bereich

Meine Spekulation über die wahre Ursache

• Im Rechenzentrum der Alruvia wird eine Sicherheits-Software eingesetzt die IP V4 adressbezogen die Anzahl und Art der Zugriffe protokolliert
• Das https:// Protokoll verwendet zum Absichern das TLS-Protokoll, ich denke auch diese Verbindungen werden genau inspiziert
• Ist das Zugriffs-Schema einer IP V4 Adresse "verdächtig" wird die IP V4 Adresse als "missbräuchlich" markiert und gesperrt
• Jegliche weitere Kontaktaufnahme wird vollständig ignoriert, es wird keine Verbindung mehr aufgebaut, dadurch der _TIMEOUT
• Ich vermute 1 & 1 hat aus Kostengründen einen sehr engen IP V4 Adressbereich
• Normal ist, dass alle 1 und 1 Kunden diesen engen Adressbereich gemeinsam nutzen und dabei dutzende Anschlüsse gleichzeitig auch eine einzelne IP V4 Adresse
• So ist es denkbar dass innerhalb weniger Minuten zahlreiche gleichzeitige Verbindungsversuche mit verschiedenen TLS- Identitäten auf einer IP V4 Adresse beobachtet werden
• Das sieht aus wie ein Angriff eines automatischen Systems zum "Niederzwingen der Performance" oder zum "Ausprobieren zahlreicher Passworte"
• Dies ist eine fehlerhafte Einschätzung der Sicherheits-Software unter Missachtung der technischen Realitäten von Dual Stack Lite (DS-Lite)
• Ich denke in der Folge wird die Quell IP V4 Adresse von 1&1 als "böse" markiert, und somit zahlreiche 1und1 Kunden ausgesperrt

Lösungen

kurzfristig

• Korrekte Konfiguration der Sicherheits-Software
• oder Einpflegen der IP-V4 Adressen des Providers 1 und 1, Policy-Änderung bei diesen Adressen

langfristig

• vbkraichgau.de wird ausschließlich auf eine IP V4 Adresse aufgelöst (A-Record), eine IP V6 Adresse wird nicht alternativ angeboten (AAAA-Record)
  • Würde vbkraichgau.de auch eine IP V6 Adresse im DNS liefern würde das Problem nicht entstehen, da sich Clients vorrangig via IP V6 verbinden würden
  • Würden sich Clients über IP V6 Verbinden wäre die fälschlicherweise angenommene 1:1 Beziehung (eine Adresse<->einige wenige Nutzer) wieder näher an der Relatität