Raspberrypi.gateway

• Ziel ist es dass sich der Raspberry Pi mit einem WLAN verbindet, dieses ist in meinem Fall ein durch ein Handy aufgespannter HotSpot
• Er ist per LAN an das lokale Netz angebunden, und soll eigentlich eine fest IP-Adresse haben
• Er soll als Gateway dem Netz dienen

Problem 1

• LAN sollte eine statische Adresse erhalten, wenn ich aber in interfaces was formuliere geht wlan0 DHCP nicht mehr

Lösung?

/etc/dhcpcd.conf

interface eth0
static ip_address=10.0.0.1/24

-> noch testen!

Problem 2

• sind beide interfaces ungenannt wird immer wieder die standard-route des LAN gesetzt
• dann haben wir 2 standard-Route, die vom wlan0 ist aber die einzig richtige

Problem 3

• /etc/dhcp/dhcpcd.conf scheint wirkungslose zu sein

Problem 4

• der Raspi macht zwar einen internen automatischen reconnect auf das wlan0
• aber er holt sich keine IP Adresse ab, das wlan0 INterface stellt sich so dar:

wlan0: flags=4098<BROADCAST,MULTICAST>  mtu 1500
        ether b8:27:eb:6d:1b:a7  txqueuelen 1000  (Ethernet)
        RX packets 424373  bytes 46354455 (44.2 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 1173317  bytes 1621973317 (1.5 GiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

• erst ein

systemctl restart dhcpcd

• konfiguriert die wlan0 Verbindung wieder ordentlich

wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.115.49  netmask 255.255.255.0  broadcast 192.168.115.255
        inet6 2a02:8071:2bce:a600:fc2f:13ef:88f5:bb7d  prefixlen 64  scopeid 0x0<global>
        inet6 fe80::d98:f2c6:7b55:c5c5  prefixlen 64  scopeid 0x20<link>
        ether b8:27:eb:6d:1b:a7  txqueuelen 1000  (Ethernet)
        RX packets 424734  bytes 46379214 (44.2 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 1173430  bytes 1622028515 (1.5 GiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

• will man das ev. automatisch machen, sollte man noch den "status" der technischen WLAN Verbindung prüfen ...

wpa_cli -i wlan0 status

bssid=dc:39:6f:b9:5a:a0
freq=2437
ssid=OrgaMon
id=0
mode=station
pairwise_cipher=CCMP
group_cipher=CCMP
key_mgmt=WPA2-PSK
wpa_state=COMPLETED
ip_address=192.168.115.49
p2p_device_address=ca:b6:ff:6b:7f:f3
address=b8:27:eb:6d:1b:a7
uuid=b2f1733f-4738-5f57-956c-9262b4882b58

• die durchgestrichene Zeile fehlt dann in diesem Fall
• es sieht so aus als hätte sich die p2p Adresse geändert:

# "hier" wurde die ip addresse Verloren 
# 
p2p_device_address=ca:b6:ff:6b:7f:f3
#
# mit dieser neuen Adresse ging es dann wieder
#
p2p_device_address=5e:9c:31:33:9d:17

• Ich denke es liegt am AVM Fritz!Box Mesh und der Streering Technologie
  • https://patents.google.com/patent/WO2018096383A1/en
• Ich vermute der Raspi "soll" / "will" / "muss" zu einem anderen Node, dies verändert die p2p_device_address
• das funktioniert, aber er rechnet nicht damit dass die IP Adresse bleiben darf!

"routes" option beim DHCPD Server verhindern

• Wir betreiben wegen "Problem 1" beide Interfaces im DHCP Modus
• Verwirrung entsteht jedoch dass zusammen mit der IP Adresse für eth0 auch ein Gateway versendet und eigetragen wird
• da kabelgebunden hat es eine niedrigere Metrik und wird dem wlan0-gateway vorgezogen
• dies kann man auf seinem DHCPD Server verhindern, es ist jedoch eine undokumentierte Funktion
• option routers false;
• KORREKTUR: der Routername "false" kann nur nicht aufgeklöst werden, das ist kein Feature sondern ein Seiteneffekt, der zufällig geholen hat, ich mach das jetzt mit gruppen ...

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

aktuelles Router-Script

bisher

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

#
#
#
route del default gw 192.168.115.47
dhcpcd -S ip_adress=192.168.115.47/24 eth0
iptables -t nat -A POSTROUTING -o wlan0 -j MASQUERADE

#
# Ausgabe zur Diagnose
#
iptables -t nat -L -v -n
route -vn

#

neu

• Es gibt einen 2. Internet-Zugang (FritZ!Box 2).
• Dieser soll als weiteres/alternatives Gateway im normalen Netz genutzt werden.
• Dabei ist ein Raspberry Pi über LAN Kabel an die 2. Fritz!Box angeschlossen
• Er ist zudem Teilnehmer des primären/normalen WLANS mit dem alle ins Internet gehen
• Ziele
  • die Fritz!Box Oberfläche der 2. Box soll aus dem normalen WLAN aufrufbar sein
  • der RPi soll als Gateway für den alternativen INternet-Zugang dienen

#!/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
• Bei im lokalen WLAN angemeldeten Handys funktioniert die "VR Banking App" dann auch nicht
• Alle anderen https://, http:// Seiten im Internet funktionieren der Anschluss ist 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

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

• 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
• Einpflegen der IP-V4 Adressen des Providers 1 und 1, Policy-Änderung bei diesen Adressen