Raspberrypi.router: Unterschied zwischen den Versionen
Zur Navigation springen
Zur Suche springen
Root (Diskussion | Beiträge) Keine Bearbeitungszusammenfassung |
Root (Diskussion | Beiträge) |
||
(4 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt) | |||
Zeile 12: | Zeile 12: | ||
[[Datei:Rasp-Router-Project.jpg|768px]] | [[Datei:Rasp-Router-Project.jpg|768px]] | ||
=== Software === | |||
* Wegen den virtuellen LAN Schnittstellen | |||
** <code>apt-get install vlan</code> | |||
* Wegen domadd | |||
** <code>apt-get install whois</code> | |||
** <code>groupadd www</code> | |||
* Wegen der korrekten Einstellung der Zeitzone | |||
** <code>dpkg-reconfigure tzdata</code> | |||
== Ziele == | == Ziele == | ||
Zeile 18: | Zeile 28: | ||
* Mit Hilfe eines Smart-Switches soll ein Raspi an 3 Internet-Zugänge geschaltet werden (2 Fritz! Boxen und 1 Kabelmodem) | * Mit Hilfe eines Smart-Switches soll ein Raspi an 3 Internet-Zugänge geschaltet werden (2 Fritz! Boxen und 1 Kabelmodem) | ||
* Über die einzelne Netzwerkschnittstelle, erhalte ich durch die VLAN-Infrastruktur 5 Netzwerkschnittstellen | |||
* Er soll aus allen 3 WAN Schnittstellen Anfragen beantworten können, als Anfang 3x SSH-Zugang | * Er soll aus allen 3 WAN Schnittstellen Anfragen beantworten können, als Anfang 3x SSH-Zugang | ||
* In der Standard-Konfiguration liefern beide Fritzboxen identische Gateway Adressen | * In der Standard-Konfiguration liefern beide Fritzboxen identische Gateway Adressen | ||
Zeile 33: | Zeile 44: | ||
* Für den eigenen Internet-Zugang: Er soll selbst umschalten können welchen Internet-Zugang er im Moment verwenden will | * Für den eigenen Internet-Zugang: Er soll selbst umschalten können welchen Internet-Zugang er im Moment verwenden will | ||
* Für Internet-Clients: Er soll sich für einzelne Clients merken, welchen Internet-Zugang diese benutzen sollen | * Für Internet-Clients: Er soll sich für einzelne Clients merken, welchen Internet-Zugang diese benutzen sollen | ||
=== Switch === | === Switch === | ||
Zeile 534: | Zeile 477: | ||
[[Raspberry.solar]]<br> | [[Raspberry.solar]]<br> | ||
[[Raspberry.counter]] | [[Raspberry.counter]]<br> |
Aktuelle Version vom 22. September 2018, 12:02 Uhr
zurück zur Hauptseite raspberrypi
ACHTUNG: Projekt-Status: Funktioniert noch nicht!
Überblick
Schematisch
Real
Software
- Wegen den virtuellen LAN Schnittstellen
apt-get install vlan
- Wegen domadd
apt-get install whois
groupadd www
- Wegen der korrekten Einstellung der Zeitzone
dpkg-reconfigure tzdata
Ziele
Hauptziel
- Mit Hilfe eines Smart-Switches soll ein Raspi an 3 Internet-Zugänge geschaltet werden (2 Fritz! Boxen und 1 Kabelmodem)
- Über die einzelne Netzwerkschnittstelle, erhalte ich durch die VLAN-Infrastruktur 5 Netzwerkschnittstellen
- Er soll aus allen 3 WAN Schnittstellen Anfragen beantworten können, als Anfang 3x SSH-Zugang
- In der Standard-Konfiguration liefern beide Fritzboxen identische Gateway Adressen
- In meiner Konfiguration vergaben die Fritz!Box dem RASPI auf beiden Interfaces dieselbe IP Adresse, DAS WILL ICH SO LASSEN
FRITZ!BOX 1 <-- DHCP --> eth0.2 (192.168.178.20, Gateway 192.168.178.1) FRITZ!BOX 2 <-- DHCP --> eth0.3 (192.168.178.20, Gateway 192.168.178.1)
- Die Netze sind nicht gekoppelt, die sollen sich auch nicht sehen, der Raspi soll einfach Anfragen auf diesen beiden INterfaces beantworten können!
weitere denkbare Ziele
- Für den eigenen Internet-Zugang: Er soll selbst umschalten können welchen Internet-Zugang er im Moment verwenden will
- Für Internet-Clients: Er soll sich für einzelne Clients merken, welchen Internet-Zugang diese benutzen sollen
Switch
- Also der Raspi hat ja nur eine Netzwerkschnittstelle (mit 100 MBit)
- da ich aber 5 Netzwerkschnittstellen brauche route ich alles über "eth0" an einen Smart-Switch
- Dieser hat 8 Anschlüsse, ich könnte also 7 Netzwerkkarten für den Raspi simulieren ein Port fällt weg wegen des Uplink
- Ich brauche aber nur 5 Netze, der Switch darf also auch ein bischen als stinknormaler Switch arbeiten
- Port 1 bis 3, eth0.1
- Port 4, eth0.2
- Port 5, eth0.3
- Port 6, eth0.4
- Port 7 bis 8, eth0.5
- Diese VLAN-Schnittstellen (eth0.1 bis eth0.5) sind sauber voneinander getrennt und die Pakete können nicht ausbrechen
- Die Bandbreite aller Schnittstellen ist natürlich in der Summe immer nur maximal 100 MBit, aber wer hat schon ein WAN, das sooo schnell ist
TP-LINK TL-SG2008 +======+======+======+======+======+======+======+======+ Port | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | +======+======+======+======+======+======+======+======+ Funktion |MGMNT1|MGMNT2|RASPI |WAN1 |WAN2 | WAN3 |LAN |LAN | +======+======+======+======+======+======+======+======+ Raspi- | | | | | | | | | Interface |eth0.1|eth0.1|eth0.1|eth0.2|eth0.3|eth0.4|eth0.5|eth0.5| +======+======+======+======+======+======+======+======+
1 .. 3 = Management Port - 1 Zugang zum Smart-Switch (192.168.0.1) 2 - Frei - 3 zum Raspi (192.168.0.2) 4 = zum DSL1 5 = zum DSL2 6 = zum Kabel-BW 7 .. 8 = LAN für Clients
Smart Switch Config
Tagged? oder Untagged?
- Bei der Switch Konfiguration muss man entscheiden ...
- Ist ein Port Teilnehmer eines VLANs
- Ich glaube das ist leicht zu entscheiden, man hat ja bewusst die AUfteilung in Gruppen gewollt jetzt muss man die Mitgliedschaft regeln
- Soll ein Port "Tagged" oder "Untagged" betrieben werden
- Ein weiterer Router, Switch oder Server schliesst man an einen Tagged Port an, da nur über diesen VLAN IDs sichtbar transportiert werden
- Normale Clients sollten normalerweise vom VLAN nichts mitbekommen, wenn man Clients zwingt VLAN IDs zu senden/empfangen können diese auch aus diesem Netz ausbrechen
- Normale Clients also immer an einem "untagged" Port
- "Betreiber" der einzelnen VLANs müssen immer Mitglied eines VLANs an allen gewünschten Ports sein, also insbesondere auch am "Uplink" Port (in meinem Fall Port "3")
- Ist ein Port Teilnehmer eines VLANs
TP-Link Config
- die richtige VLAN-Konfiguration:
- Wie ist das zu verstehen:
- Zeile "1" beschreibt das VLAN mit der ID "1", es spricht nur an den Ports 1,2 und 3. Alle anderen Ports bekommen nix mit. Port 1-2 verhalten sich dabei unauffällig, an Port 3 haben alle Pakete ein zusätzliches VLAN Tag.
- Port 3 ist interessant: Er ist Mitglied aller VLANs, auf dem Port geht es also richtig ab, alle Pakete MÜSSEN deshalb auch "getagged" transportiert werden, sonst bricht das Chaos aus
- Die VLAN Fähigkeit des RASPI verteilt den ganzen VLAN-Verkehr auf eth0 in die Schnittstellen eth0.1 bis eth0.5
eigene individuelle MAC-Adressen
- hm, alle "." interfaces haben (ohne weitere Konfiguration) alle dieselbe MAC-Adresse
- ich habe das jetzt nicht als Problem eingestuft da ja alle VLANs voneinander isoliert sind
- das muss aber nicht sein, ich finde es erleichtert auch mal die Fehlersuche am Switch, wenn jede "virtuelle Netzwerkkarte" seine eigene MAC Adresse hat:
# interfaces(5) file used by ifup(8) and ifdown(8) # Please note that this file is written to be used with dhcpcd # For static IP, consult /etc/dhcpcd.conf and 'man dhcpcd.conf' # Include files from /etc/network/interfaces.d: source-directory /etc/network/interfaces.d auto lo iface lo inet loopback auto eth0 iface eth0 inet manual pre-up modprobe 8021q post-up ifup eth0.1 post-up ifup eth0.2 post-up ifup eth0.3 post-up ifup eth0.4 # post-up ifup eth0.5 # Management iface eth0.1 inet static hwaddress ether b8:27:eb:3b:90:81 address 192.168.0.2 netmask 255.255.255.0 # WAN1 - DSL1 iface eth0.2 inet dhcp hwaddress ether b8:27:eb:3b:90:82 # WAN2 - DSL2 iface eth0.3 inet dhcp hwaddress ether b8:27:eb:3b:90:83 # WAN3 - KabelBW iface eth0.4 inet dhcp hwaddress ether b8:27:eb:3b:90:84 # LAN iface eth0.5 inet static hwaddress ether b8:27:eb:3b:90:85 address 192.168.115.39 netmask 255.255.255.0 # allow-hotplug wlan0 iface wlan0 inet manual wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf allow-hotplug wlan1 iface wlan1 inet manual wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf
- Ausgabe von
ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000 link/ether b8:27:eb:3b:90:79 brd ff:ff:ff:ff:ff:ff 3: eth0.1@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000 link/ether b8:27:eb:3b:90:81 brd ff:ff:ff:ff:ff:ff 4: eth0.2@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000 link/ether b8:27:eb:3b:90:82 brd ff:ff:ff:ff:ff:ff 5: eth0.3@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000 link/ether b8:27:eb:3b:90:83 brd ff:ff:ff:ff:ff:ff 6: eth0.4@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000 link/ether b8:27:eb:3b:90:84 brd ff:ff:ff:ff:ff:ff
Probleme
Das Routing stimmt nicht!
- Wenn 2 (oder mehr) Interfaces per dhclient eine IP-Adresse beziehen setzen alle nacheinander die einzige/global wirksame Standard-Route. Dabei gibt es immer nur einen "Gewinner", bei alle anderen Interfaces funktioniert das Routing nicht mehr.
- Die Ursache ist dass eigehende Anfragen NICHT über das "eigene" Gateway zurück ins Internet geschickt werden, sondern über das Gateway eines anderen WAN Zugangs, das funktioniert natürlich nicht, das falsche Gateway kann mit den Paketen überhaupt nichts anfangen und verwirft sie.
- Es wird der Grundsatz "What happens in Vegas, stays in Vegas" missachtet, also übersetzt eingehender Netzwerkverkehr im WAN1 geht auch über WAN1 wieder zurück
- Problem 1: die Default Route
- Jeder DHCP-Erfolg auf einem VLAN setzt die Default Route des ganzen Raspi! Irre! Steinzeitlich!
- Täter ist /sbin/dhclient-script Zeile "247"
- Problem 2: die IP-Adress-Routen
- An 2 WLANs gibt mir der Router 192.168.1.* Adresse, ich bin also mit WAN1 und WAN2 in einem ähnlich klingenden Netz, was zu Problemen führen kann!
Ziel
- Was auf WAN1 passiert, bleibt auf WAN1, und geht NICHT über die Default-Route in ein anderes Netz uuuuaaaahhhh
- analog WAN2
- analog WAN3
- analog LAN
Weg zur Lösung
Anfrage kommt an
mit
tcpdump -i eth0.2 port 22 and '(tcp-syn|tcp-ack)!=0'
bzw.
tcpdump -i eth0.3 port 22 and '(tcp-syn|tcp-ack)!=0'
bzw.
tcpdump -i eth0.2 'tcp port 22'
konnte ich beweisen dass die Anfrage ankommt, aber leider die Antwort nicht geroutet werden kann.
Anfrage kommt immnoch an
iptables -I INPUT -p tcp --dport 22 --syn -j LOG --log-prefix "SSH SYN: "
jetzt wird sauber auf beiden interfaces protokolliert wann eine ssh-Anfrage ankommt
Jun 21 16:09:13 raspberrypi kernel: [ 1450.098906] SSH SYN: IN=eth0.3 OUT= MAC=b8:27:eb:3b:90:83:c8:0e:14:e8:8d:59:08:00:45:00:00:34:19:1e:40:00:76:06:63:f3:d9:08:3b:ed SRC=217.8.59.237 DST=192.168.178.20 LEN=52 TOS=0x00 PREC=0x00 TTL=118 ID=6430 DF PROTO=TCP SPT=65299 DPT=22 WINDOW=8192 RES=0x00 SYN URGP=0
oder eben
Jun 21 16:09:16 raspberrypi kernel: [ 1452.580219] SSH SYN: IN=eth0.2 OUT= MAC=b8:27:eb:3b:90:82:c8:0e:14:e7:81:86:08:00:45:00:00:34:19:1f:40:00:77:06:62:f2:d9:08:3b:ed SRC=217.8.59.237 DST=192.168.178.20 LEN=52 TOS=0x00 PREC=0x00 TTL=119 ID=6431 DF PROTO=TCP SPT=65300 DPT=22 WINDOW=8192 RES=0x00 SYN URGP=0
Routing, besseres Verständnis nötig
- DIe Lösungen "Dual WAN" funktionieren alle nicht, ich brauche mehr Infos zum Routing allgemein
- http://linux-ip.net/html/routing-rpdb.html
- http://linux-ip.net/html/routing-selection.html#routing-selection-adv
manuelles Umschalten
- eth0.2 ist aktiv nach dem booten, da sie das erste interface ist das die default route mit "add" anlegt, folgendes "add"s gehen schief
ip route replace default via 192.168.178.1 dev eth0.3
- und "so" wieder zurück
ip route replace default via 192.168.178.1 dev eth0.2
Lösung mit interface Groups?
- /etc/iproute2/groups
# device group names 0 default 1 wan
ip link set dev eth0.2 group wan ip link set dev eth0.3 group wan ip link set dev eth0.4 group wan
- Ip Tables kann dann wiederum anhand der Group eine Regel erstellen
devgroup Match device group of a packets incoming/outgoing interface. [!] --src-group name Match device group of incoming device [!] --dst-group name Match device group of outgoing device
Lösung mit 3 Routing Tabellen
/etc/iproute2/rt_tables
# # reserved values # 255 local 254 main 253 default 0 unspec # # local # 10 lan 11 mgm 12 wlan # # remote # 101 wan1 102 wan2 103 wan3
ip route add table wan1 default via 192.168.178.1 dev eth0.2 ip route add table wan2 default via 192.168.178.1 dev eth0.3 ip route add table wan3 default via 192.168.0.1 dev eth0.4 ip rule add iif eth0.2 table wan1 ip rule add iif eth0.3 table wan2 # # Wirksam machen # ip route flush table cache
Regelwerk
- Ich finde das Problem ist die "rule" Prio "0", die mir alles zerhagelt!
># ip rule show 0: from all lookup local 32766: from all lookup main 32767: from all lookup default
- Ich lege mal eine Kopie der Regel "0" an, damit ich mich nicht abschiesse
># ip rule add prio 1001 table local ># ip rule del prio 0 ># ip rule show 1001: from all lookup local 32766: from all lookup main 32767: from all lookup default
- Es geht alles noch, so jetzt kann ich "ganz" hohe prio bei "meinen" Regeln sicherstellen
># ip rule add prio 10 iif eth0.2 table wan1 ># ip rule add prio 11 iif eth0.3 table wan2
ip rule add prio 1001 table local
- Jetzt brauche ich in den "wan1", "wan2" Tabellen eine default route
># ip route add default via 192.168.178.1 dev eth0.2 table wan1 ># ip route add default via 192.168.178.1 dev eth0.3 table wan2
- Jetzt brauchen wir noch die normalen IP-Adresse Routings
># ip -4 addr add 192.168.178.20/255.255.255.0 broadcast 192.168.178.255 dev eth0.3 label eth0.3
USB LAN Adapter
CSL USB 3.0 to Ethernet Adapter B00YHAD5C4
[80428.511758] usb 1-1.2: new high-speed USB device number 4 using dwc_otg [80428.613449] usb 1-1.2: New USB device found, idVendor=0bda, idProduct=8153 [80428.613469] usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=6 [80428.613483] usb 1-1.2: Product: USB 10/100/1000 LAN [80428.613495] usb 1-1.2: Manufacturer: Realtek [80428.613508] usb 1-1.2: SerialNumber: 000001000000 [80428.648120] usbcore: registered new interface driver r8152 [80428.652560] usbcore: registered new interface driver cdc_ether [80428.741764] usb 1-1.2: reset high-speed USB device number 4 using dwc_otg [80428.879736] r8152 1-1.2:1.0 eth1: v1.08.2 [80429.902229] IPv6: ADDRCONF(NETDEV_UP): eth1: link is not ready [80451.876927] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
eth1 Link encap:Ethernet HWaddr 00:e0:7c:c8:65:01 inet addr:169.254.231.205 Bcast:169.254.255.255 Mask:255.255.0.0 inet6 addr: fe80::c16:fe4a:14e4:19ea/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:165 errors:0 dropped:0 overruns:0 frame:0 TX packets:54 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:17037 (16.6 KiB) TX bytes:12727 (12.4 KiB)
TECKNET UL466G USB2.0 Ethernet Adapter
[81593.979182] usb 1-1.4: new high-speed USB device number 5 using dwc_otg [81594.091945] usb 1-1.4: New USB device found, idVendor=0b95, idProduct=772b [81594.091967] usb 1-1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [81594.091980] usb 1-1.4: Product: AX88772C [81594.091993] usb 1-1.4: Manufacturer: ASIX Elec. Corp. [81594.092005] usb 1-1.4: SerialNumber: 00008E [81595.972979] asix 1-1.4:1.0 eth1: register 'asix' at usb-3f980000.usb-1.4, ASIX AX88772B USB 2.0 Ethernet, 00:0e:c6:c8:2f:5e [81595.973174] usbcore: registered new interface driver asix [81596.910750] IPv6: ADDRCONF(NETDEV_UP): eth1: link is not ready [81610.483350] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready [81610.486285] asix 1-1.4:1.0 eth1: link up, 100Mbps, full-duplex, lpa 0x45E1
eth1 Link encap:Ethernet HWaddr 00:0e:c6:c8:2f:5e inet addr:169.254.231.205 Bcast:169.254.255.255 Mask:255.255.0.0 inet6 addr: fe80::6af:2e73:c06f:b5e6/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:52 errors:0 dropped:0 overruns:0 frame:0 TX packets:42 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:6009 (5.8 KiB) TX bytes:10062 (9.8 KiB)
ANKER A7610 USB3.0 to Gigabit Ethernet Adapter
[81856.420811] usb 1-1.5: new high-speed USB device number 6 using dwc_otg [81856.522513] usb 1-1.5: New USB device found, idVendor=0bda, idProduct=8153 [81856.522535] usb 1-1.5: New USB device strings: Mfr=1, Product=2, SerialNumber=6 [81856.522548] usb 1-1.5: Product: USB 10/100/1000 LAN [81856.522561] usb 1-1.5: Manufacturer: Realtek [81856.522573] usb 1-1.5: SerialNumber: 000001000000 [81856.620815] usb 1-1.5: reset high-speed USB device number 6 using dwc_otg [81856.759722] r8152 1-1.5:1.0 eth1: v1.08.2 [81858.011067] IPv6: ADDRCONF(NETDEV_UP): eth1: link is not ready [81868.559767] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
eth1 Link encap:Ethernet HWaddr 00:e0:8f:00:8f:82 inet addr:169.254.231.205 Bcast:169.254.255.255 Mask:255.255.0.0 inet6 addr: fe80::e099:3087:1b1d:de47/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:58 errors:0 dropped:0 overruns:0 frame:0 TX packets:42 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:7099 (6.9 KiB) TX bytes:9894 (9.6 KiB)
Erster Erfolg
- mit bestehender "default" route auf dem "anderen" Interface gelang das Routing auf dem anderen Interface:
># ip rule add from 192.168.178.20 dev eth0.3 table wan2 ># ip rule 0: from all lookup local 32762: from 192.168.178.20 iif eth0.2 lookup wan1 32763: from 192.168.178.20 iif eth0.3 lookup wan2 32764: from 192.168.178.20 lookup wan2 32765: from all iif eth0.3 lookup wan2 32766: from all lookup main 32767: from all lookup default
#> ip route show
default via 192.168.178.1 dev eth0.2 192.168.0.0/24 dev eth0.1 proto kernel scope link src 192.168.0.2 192.168.178.0/24 dev eth0.2 proto kernel scope link src 192.168.178.20 192.168.178.0/24 dev eth0.3 proto kernel scope link src 192.168.178.20
#> ip rule show table wan2 default via 192.168.178.1 dev eth0.3 192.168.178.0/24 dev eth0.3 scope link
#> ip route add 192.168.178.0/24 dev eth0.2 src 192.168.178.20 table wan1
Regel greifen nicht!
- Ich habe den Eindruck, dass <interface> basierte Regeln gar nicht greifen, Wenn jeder Netzwerk-Adapter sein "eigenes" Netz (Prefix) hat ist ja alles gut
- In meinem Fall haben aber eth0.2 und eth0.3 ggf. auch eht0.4 alle die IP-Adresse 192.168.178.20 und alle das Gateway 192.168.178.1, sowas mag das Routing nicht, sollte aber gehen oder?
- Ich will mal die Routen testen mit:
ip rule add prohibit iif eth0.3
echo 1 > /proc/sys/net/ipv4/ip_forward cat /proc/sys/net/ipv4/ip_forward
Ausblick
- Ich träume aber von einem Raspi 4 mit einer 1 GBit LAN Netzwerkschnittstelle, (gibts sicher in 2018!?)
- http://www.asrockrack.com/general/productdetail.de.asp?Model=C236%20WSI4-65L#Specifications
- http://www.asus.com/de/Commercial-Servers-Workstations/P9AIC2750SAS4L/specifications/