In diesem Beitrag erfährst Du, wie Du Dein Netzwerk besser strukturierst und auch das sogenannte Mac-Spoofing verhindern kannst (NoArp – Methode).
Aber was ist NextHop? Genau das erkläre ich Euch jetzt und welche Vorteile das mit sich bringen kann. 🙂
Vorteile von Routing via NextHop
- Kein ProxyArp im Linux Kernel mehr benötigt, was die Sicherheit verbessern und Komplikationen im Netzwerk verhindern kann.
- Ein reines Statisches Routing ohne Proxy oder anderen Hilfsmechanismen.
Vorteile der NoArp Methode:
- Mac-Spoofing verhindern
- Genau zu wissen, wo und welcher Client das Internet oder sich im Lokalen Netzwerk befindet.
- Selbst die Zuweisungen erteilen über die Arp Table.
Nachteile der NoArp Methode:
- Manuelles Eintragen notwendig
- Bei vielen Netzwerkteilnehmern sehr aufwendig
1. NextHop Routing über GRETAP (Arp)
Um von einem Ziel-Rechner die Pakete zu übermitteln, werden sogenannte GRE Pakete an das Ziel-Netzwerk geleitet.
Dabei hat GRE eine schnelle Datenrate, was eben schnelle Geschwindigkeiten je nach Netzwerk ermöglichen kann.
Das gilt zu beachten:
GRE (Layer 3 Protocol) – Hier müsst Ihr Euch das so vorstellen: Host A → Host B <= → Host C (KVM) – Der Trafficaustausch erfolgt hier erst über Host B wobei dies etwas mit der Konfiguration aufwendiger ist.
GRETAP (Layer 2 – Protokoll) – Hier haben wir den Vorteil, dass wir direkt zum Router uns mit unseren Hypervisor verbinden können als z.B Gateway. | Host A → (Host B als Transmitter) <= Host C (KVM).
# nano /etc/sysctl.conf
net.ipv4.ip_forward=1
net.ipv6.conf.all.forwarding=1# Jetzt das IP-Forwading im Kernel aktivieren
sysctl -p# nano v6-gretap.sh
#!/bin/bash
# Abfrage der lokalen und entfernten IP-Adresse
read -p "Gib die lokale IP-Adresse für den GRE-Tunnel ein: " local_ip
read -p "Gib die entfernte IP-Adresse für den GRE-Tunnel ein: " remote_ip
read -p "Gib den Namen für das GRE-Interface ein (z.B. gre1): " tunnel_name
# Tunnel erstellen
echo "Erstelle GRE-Tunnel $tunnel_name mit lokaler IP $local_ip und entfernter IP $remote_ip..."
ip link add "$tunnel_name" type ip6gretap local "$local_ip" remote "$remote_ip"
ip link set "$tunnel_name" up
echo "GRE-Tunnel $tunnel_name wurde erstellt."Kopiert nun dieses quelloffene Skript und fügt es im Anschluss mit dem nano Editor ein und speichert es je nach Wunsch als .sh Skript auf Eurem Linux Server.
Dabei dient das Skript zum Aufbau eines GRETAP Tunnels über IPv6
# nano v4-gretap.sh
#!/bin/bash
# Abfrage der lokalen und entfernten IP-Adresse
read -p "Gib die lokale IP-Adresse für den GRE-Tunnel ein: " local_ip
read -p "Gib die entfernte IP-Adresse für den GRE-Tunnel ein: " remote_ip
read -p "Gib den Namen für das GRE-Interface ein (z.B. gre1): " tunnel_name
# Tunnel erstellen
echo "Erstelle GRE-Tunnel $tunnel_name mit lokaler IP $local_ip und entfernter IP $remote_ip..."
ip link add "$tunnel_name" type gretap local "$local_ip" remote "$remote_ip"
ip link set "$tunnel_name" up
echo "GRE-Tunnel $tunnel_name wurde erstellt."Für IPv4 selbstverständlich einmal angepasst, wobei IPv6 hier mehr empfohlen wird.
# Host A
ip addr add 192.168.0.1/24 dev gre1
ip route replace 5.230.x.x via 192.168.0.2 dev gre1# Host B
ip addr add 192.168.0.2/24 dev gre1
ip route replace 5.230.x.x via 192.168.0.2 dev gre1# KVM Container – IP Konfiguration Beispiel
# IP
5.230.x.x/32
# Gateway
192.168.0.1# Püft nun ob die Öffentliche IPv4 Adresse pingt.
ping -c 1 5.230.x.x2. NextHop Routing über GRETAP (NoArp)
Zunächst müssen wir verstehen was NoArp nochmal genau bedeutet:
Es gilt zu beachten, dass man alle MAC zu IP & Interface selbst zuweisen muss.
Der Nachteil ist dann ein größerer Aufwand zwecks Eintragung aller einzelnen Geräte.
Das Gute: Zu wissen, was man festgelegt hat und welcher Endnutzer / KVM dahinter steckt.
Vorgehensweise
Ich werde jetzt einen GRETAP auf dem Host eröffnen, zu einem in Düsseldorf stehende Umgebung.
Lassen wir dies einmal notieren: DUS → FRA (Bridged Ports – Layer 2 Routing).
Dabei werden wir einen Virtuellen GRETAP Tunnel auch Bridgen um dann direktes Routing zu ermöglichen.
Um jetzt eine Verbindung aufzubauen via GRE, empfehle ich die oben vorgestellten Skripte zu benutzten.
Das macht die Arbeit etwas Komfortabler.
# Jetzt bei Host A: Eine zusätzliche öffentliche IPv4-Adresse Routen zu Host B
ip route replace 85.93.x.x via 172.35.1.2 dev index001# Fügt dus001 zur vmbr2 hinzu
# Somit wäre direkter Austausch auch mit den VMs möglich
brctl addif vmbr2 dus001Dabei werden diese Einträge statisch gesetzt. Ein kleiner Fehler bei der MAC Zuweisung und der Ping könnte da nicht klappen.
Ich habe index001 (Host A) die eigene Interface MAC eingetragen + Remote und auch beim Remote die z.B 172.35.1.1 eingetragen, damit ein Ping erst möglich werden kann.
Natürlich könnte man darüber nachdenken, es mit Skripten oder eigenen Netzwerk-APIs zu automatisieren.
Experiment | NoArp: Mit einer Öffentlichen IPv4 + LXC Container Test
# Auf Host B
root@pve01:~# arp -n | grep vmbr2
85.93.8.36 ether bc:24:11:21:27:66 CM vmbr2
172.35.1.1 ether f6:da:e5:95:f2:f5 CM vmbr2
172.35.1.2 ether de:8c:01:6e:42:c4 CM vmbr2
# Auf Host A
root@host01:~# arp -n | grep index001
172.35.1.2 ether de:8c:01:6e:42:c4 CM index001
85.93.8.36 ether bc:24:11:21:27:66 CM index001
172.35.1.1 ether f6:da:e5:95:f2:f5 CM index001
# Innerhalb des LXC
ip neigh change 172.35.1.1 lladdr f6:da:e5:95:f2:f5 dev eth0
# Danach ist die IPv4 aus dem Internet erreichbar :)
Fazit
Es ist eher besser für Nexthop wenn wir vom Großen and ganzen reden, nähmlich im Produktiv Betrieb damit zu gehen, eher die NoArp Methode nicht empfohlen wird durch die Großen aufwände.
Arp Methode nehmen + Via Nexthop das wäre schon ausreichend 🙂
Wer aber sein Zuhause so richtig schützen möchte so ist NoArp zwar aufwendiger aber verhindert alle z.B Ungebetenen Gäste aus dem WLAN nicht zuzulassen.
Dies ist aber nur ein Beispiel von vielen.
Und um als Abschluss sagen zu können:
Das ist reines Statisches Routing, keine Proxy Arp oder NDP dahinter die das Managen.
Schreibe einen Kommentar