Raspberrypi.router

Aus OrgaMon Wiki
Zur Navigation springen Zur Suche springen

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")

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

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

Projekte

Raspberry.solar
Raspberry.counter

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