21
Bearbeitungen
Änderungen
update: Uniklinik Uplink Traffic in eigenes VLAN
* Aufgabe: BATMAN Pakete verarbeiten
* Aufgabe: BATMAN Pakete verarbeiten
* Hardware: WR841v9
* Hardware: WR841v9
* Config: Siehe [[Howto/Backbone-Client|Backbone-Client Howto]], jedoch leicht unterschiedliche Switch + VLAN Config, da der 841er nur VLAN IDs bis 15 unterstützt:
* Config: Siehe [[Howto/Backbone-Client|Backbone-Client Howto]], jedoch leicht unterschiedliche Switch + VLAN Config, da der 841er nur VLAN IDs bis 15 unterstützt. Infos zur Nummerierung der LAN Ports (Gelbe Buchsen) siehe [https://wiki.openwrt.org/toh/tp-link/tl-wr841nd#switch_configuration OpenWRT Wiki].
Alle LAN ports (Gelbe Buchsen) VLAN an:
Alle LAN Ports raus aus dem VLAN 1 (=kein VLAN), nur die CPU an Port 0 bleibt drin:
<pre>
<pre>
config switch_vlan
config switch_vlan
Weil die VLAN id 65 jedoch zu hoch für unseren 841er ist, packen wir auf dem BB-Client (d.h. auf der Nanostation) um und zwar in das VLAN id 2, siehe Screenshot oben.
Weil die VLAN id 65 jedoch zu hoch für unseren 841er ist, packen wir auf dem BB-Client (d.h. auf der Nanostation) um und zwar in das VLAN id 2, siehe Screenshot oben.
Zusätzliche Konfiguration auf dem 841:
Zusätzliche Konfiguration auf dem 841: Neues VLAN mit der id 2 erzeugen (an allen Ports akzeptieren) ...
<pre>
<pre>
config switch_vlan
config switch_vlan
option ports '0t 1t 2t 3t 4t'
option ports '0t 1t 2t 3t 4t'
</pre>
</pre>
... und das neue VLAN Interface (<tt>eth0.2</tt>) ins Interface <tt>wan</tt> bridgen:
<pre>
<pre>
config interface 'wan'
config interface 'wan'
#option ifname 'eth1'
#option ifname 'eth1' # das hier auskommentieren
list ifname 'eth1'
list ifname 'eth1' # stattdessen "list ifname ..." verwenden
list ifname 'eth0.2' # neues vlan interface
option multicast_querier '0'
option peerdns '0'
option auto '1'
option type 'bridge'
option proto 'dhcp'
option macaddr '0e:53:a1:94:26:60'
</pre>
In dieser Konfiguration sollte der VipriNet Router bereits eine IP aus dem lokalen LAN erhalten haben. Um das zu prüfen pingen wir alle Kisten im LAN an und lassen uns dann die MAC Adressen geben:
<pre>
$ nmap -sP 192.168.16.0/24
$ arp -a
...
$? (192.168.16.153) at 00:18:ca:80:11:7c [ether] on enp0s25
...
</pre>
Dank der [https://www.wireshark.org/tools/oui-lookup.html OUI Suche] wissen wir, dass ''00:18:CA'' zur 'Viprinet GmbH'' gehört.
[[Image:Standort afe luci vlan.png|thumb|right|400px|Die VLAN Konfiguration in LuCi: Ein neues VLAN mit der id 9 wird erstellt und die CPU und der erste LAN Port, an dem sich das LAN befindet, zugeordnet. ''Tagged'' bedeutet, dass die Pakete beim Verlassen des Routers ihren VLAN tag behalten.]]
[[Image:Standorte afe luci interface.png|thumb|right|400px|Die Interface Konfiguration in LuCi: Ein neues Interface auf dem VLAN 9 wird erstellt und ein DHCP Server (nicht im Bild) darauf gestartet.]]
[[Image:Standorte afe luci firewall.png|thumb|right|400px|Die Firewall Konfiguration in LuCi: Traffic aus dem VLAN 9 wird ins WAN geNATed.]]
Es läuft zwar, aber dieses Setup hat einen '''gravierenden Nachteil''': Unser lokales LAN ist vollständig im VLAN 65 auf der Uniklinik sichtbar. Um Abhilfe zu erschaffen, sperren wir den Traffic des Multichannels Routers in ein eigenes VLAN und spendieren ihm einen seperaten DHCP Server. Es wird angenommen, dass das lokale LAN mit einem OpenWRT/Lede Router betrieben wird. (FritzBox User würden vermutlich einfach die WAN-Buchse des Gluon-Routers mit dem Gastnetzwerk der FritzBox.)
In LuCi lässt sich ein neue VLAN recht komfortabel zusammen klicken. Drei Dinge müssen neu angelegt werden:
# Neues VLAN: Wir verwenden die willkürlich eine VLAN id < 15 die lokal noch nicht verwendet wird: VLAN id 9. Diese machen wir ''tagged'' an CPU und LAN1 (an diesem Port hängt unser lokales LAN).
# Neues Interface: Wir erzeugen ein neues Interface mit den Namen ''ff_uplink'' auf <tt>eth0.9</tt> und vergeben eine willkürlich vergebene IP Range z.B. 192.168.9.0/24 an dem unten auf der Seite aktivierten DHCP Server.
# Neues Forwarding: Im Tab Firewall erstellen wir eine neues ''Zone => Fowardings'' von <tt>ff_uplink</tt> auf <tt>wan</tt>, wählen 3x die Policy ACCEPT und setzen die checkbox bei ''Masquerading''.
Test auf lokalem Rechner: (<tt>enp0s25</tt> ist das lokale Interface, verbinden mit dem OpenWRT Router)
<pre>
# ip link add link enp0s25 name enp0s25.9 type vlan id 9
# ip link set dev enp0s25.9 up
# dhclient enp0s25.9
</pre>
Das Interface enp0s25.9 sollte nun eine IP bekommen haben:
<pre>
# ip addr show dev enp0s25.9
7: enp0s25.9@enp0s25: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether b8:ae:ed:79:1f:27 brd ff:ff:ff:ff:ff:ff
inet 192.168.9.186/24 brd 192.168.9.255 scope global enp0s25.9
...
</pre>
und Wireshark sollte auch ne Menge Traffic anzeigen, da sich das neue Interface als ''default route'' eingeschummelt hat.
Wir beenden den Test mit:
<pre>
# ip link set dev enp0s25.9 up
</pre>
Auf der Seite des Gluon-Routers müssen wir nun den Traffic aus VLAN 2 (vormals VLAN 65 auf der Uniklinik), in das neue VLAN 9 packen und ins lokale LAN Richtung OpenWRT Router blasen. Konkreter: Wir erzeugen auf dem dem Gluon-Router ein neues Interface mit VLAN 9, jedoch auf dem WAN Port (''eth1.9''), bridgen es mit dem bestehenden Interface von VLAN 2 (''eth0.2''). Somit sollten die Pakete aus dem VLAN 2 ins VLAN 9 "umgepackt" werden. Im letzten Schritt holen wir <tt>eth0.2</tt> aus dem <tt>wan</tt> Interface wieder raus:
1) Wir erstellen ein neues VLAN auf <tt>eth1</tt> mit der id 9, eine IP Adresse ist nicht erforderlich (''proto 'none'''):
<pre>
config interface 'vipri_local'
option ifname 'eth1.9'
option proto 'none'
</pre>
2) Wir bridgen den Traffic aus VLAN 2 an den LAN Buchsen (<tt>eth0.2</tt>) ins das neue Interface und vice-versa:
<pre>
confih interface 'vlan_repack'
list ifname 'eth0.2'
list ifname 'eth0.2'
list ifname 'eth1.9'
option auto '1'
option type 'bridge'
</pre>
3) Die Konfiguration von <tt>wan</tt> wird wieder zurückgebaut:
<pre>
config interface 'wan'
option ifname 'eth1' # wieder "option ifname", ist na nur noch ein interface
#list ifname 'eth1' # auskommentieren / löschen
#list ifname 'eth0.2' # auskommentieren / löschen
option multicast_querier '0'
option multicast_querier '0'
option peerdns '0'
option peerdns '0'
option proto 'dhcp'
option proto 'dhcp'
option macaddr '0e:53:a1:94:26:60'
option macaddr '0e:53:a1:94:26:60'
</pre>
Das wars. Sobald der VipriNet Multichannel Router sich eine neue IP aus unserer geänderten Range geholt hat, sollte der Traffic wieder fließen. Wir können uns das auf unserem OpenWRT Router mit ''tcpdump'' anschauen:
<pre>
root@LEDE:~# tcpdump -e | grep "vlan 9"
...
</pre>
</pre>
* 841 zu lahm (gemessener durchsatz zu Uni ca 30MBit/s (Link kapazität ca. 104MBit/s) -> Futro Offloader
* 841 zu lahm (gemessener durchsatz zu Uni ca 30MBit/s (Link kapazität ca. 104MBit/s) -> Futro Offloader
* Aussenkabel durch UV festes ersetzen
* Aussenkabel durch UV festes ersetzen
* '''VLAN config anpassen, so dass nicht das LAN ins VLAN 65 exposed wird (!!) + Firewall regeln''
* '''Firewall regeln: Zugriffe auf FF server whitelisten'''