Raspberrypi.gateway: Unterschied zwischen den Versionen

Aus OrgaMon Wiki
Zur Navigation springen Zur Suche springen
 
(2 dazwischenliegende Versionen von 2 Benutzern werden nicht angezeigt)
Zeile 73: Zeile 73:
  address=b8:27:eb:6d:1b:a7
  address=b8:27:eb:6d:1b:a7
  uuid=b2f1733f-4738-5f57-956c-9262b4882b58
  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 ==
== "routes" option beim  DHCPD Server verhindern ==

Aktuelle Version vom 7. November 2019, 18:09 Uhr

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

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

Abgerufen von „https://wiki.orgamon.org/index.php?title=Raspberrypi.gateway&oldid=28487“