Raspberrypi.gateway

Aus OrgaMon Wiki
Zur Navigation springen Zur Suche springen

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 alternative Netze

  • 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
  • Es gibt 3 LAN-Netzwerke, 2x Fritz!BOX 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

Datei:Netzwerke.png

  • 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

#
# 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

Switch Heizraum

Switch Keller

Switch DG


Fraglich: Muss man das paket vlan installieren?

Switch W3

Diagnose

modinfo 8021q
tcpdump -nnei eth0 -vvv

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
Abgerufen von „https://wiki.orgamon.org/index.php?title=Raspberrypi.gateway&oldid=33204“