Raspberrypi.gateway: Unterschied zwischen den Versionen
Zur Navigation springen
Zur Suche springen
Root (Diskussion | Beiträge) (→neu) |
|||
(8 dazwischenliegende Versionen von 2 Benutzern werden nicht angezeigt) | |||
Zeile 9: | Zeile 9: | ||
* LAN sollte eine statische Adresse erhalten, wenn ich aber in interfaces was formuliere geht wlan0 DHCP nicht mehr | * 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 == | == Problem 2 == | ||
Zeile 18: | Zeile 27: | ||
* /etc/dhcp/dhcpcd.conf scheint wirkungslose zu sein | * /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 | |||
<s>ip_address=192.168.115.49</s> | |||
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 == | == "routes" option beim DHCPD Server verhindern == | ||
Zeile 26: | Zeile 97: | ||
* dies kann man auf seinem DHCPD Server verhindern, es ist jedoch eine undokumentierte Funktion | * dies kann man auf seinem DHCPD Server verhindern, es ist jedoch eine undokumentierte Funktion | ||
* <code><b>option routers false;</b></code> | * <code><b>option routers false;</b></code> | ||
* 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/ | # /etc/dhcp/ | ||
Zeile 118: | Zeile 190: | ||
== Fritz!Box == | == Fritz!Box == | ||
=== Oberfläche === | |||
* Ziel ist es, die Fritz!Box, die am eth0 Interface hängt sichtbar zu machen | * Ziel ist es, die Fritz!Box, die am eth0 Interface hängt sichtbar zu machen | ||
Zeile 136: | Zeile 210: | ||
192.168.115.0 0.0.0.0 255.255.255.0 U 303 0 0 wlan0 | 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 | 192.168.178.0 0.0.0.0 255.255.255.0 U 202 0 0 eth0 | ||
=== Freigaben === | |||
[[Datei:Freigaben-pi3x00.jpg]] |
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=COMPLETEDip_address=192.168.115.49p2p_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