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

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

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