ltcp/nftables/Präsentation/Latex/notes.xml

160 lines
3.0 KiB
XML

<notes>
<note number="3">
Zeile → genauer im Laufe des Vortrags
Vereinfachung + Redundanz-Vermeidung -> auf der übernächsten Folie näher erklärt
effizient → immer angestrebt
Fehlermeldungen -> besseres Debugging auf lange Sicht
</note>
<note number="4">
ipfw: 1994, Kernel 1.0, von FreeBSD
ipfwadm: 1996, Kernel 2.0
ipchains: 1999, Kernel 2.2
iptables: 2000, Kernel 2.3
nftables: Anfang Februar 2014, Kernel 3.13
</note>
<note number="5">
für jedes Protokoll eigene Implementierung:
einerseits: protokoll-spezifischer Code → hohe Performance durch native Ausführung
andererseits: dennoch viel Ähnlichkeit der Implementierungen
</note>
<note number="6">
NIC = Network Interface Card = Netzwerkkarte
vorgegebene Tabellen: filter, nat → zeigen
vorgebene Cains:
filter:
input
forward
output
nat:
prerouting
postrouting
</note>
<note number="7">
ein Tool, eine Kernel-Implementierung
einheitliche Schnittstelle → durch virtuelle Maschine → nur noch Byte-Code
Regeln werden im Userspace durch "nft" Tool kompiliert
siehe Folie
vergleichen: IP-Adressen direkt vergleichen
airthmetische + logische Operationen: z.B. Bereich aus IP maskieren
Änderungen: SNAT, DNAT
siehe Folie
</note>
<note number="8">
nur oberen Teil!!!
Netlink = schnelle Userspace ←→ Kernel Schnittstelle, transaktionsbasiert
NF-Tables-Core-Engine hängt sich in Netfilter ein
</note>
<note number="9">
payload = IP Packet
4 → Anzahl Bytes
offset network header + 16 → Destination IP Address in IP Header
compare → Vergleichsoperation
danach: Sprung
lookup in Tabelle → "verdict" → Urteil
→ auf rechter Seite nur Targets möglich
</note>
<note number="10">
iptables = Firewall, Tool
</note>
<note number="11">
nftables = Firewall
nft = Tool
Voraussetzung:
eigene Tabelle: beliebiger Name
eigene Chain: beliebiger Name
Chain:
type = Tabelle } jeweils aus
hook = Chain } iptables
nft inzwischen in Arch in community Repo
</note>
<note number="14">
Performance messen: möglichst viele Pakete pro Sekunde
→ Datenrate und PPS über Ethernet-Größe auftragen → Frame-Größe sukzessiv kleiner machen
→ bei ca. 300 Byte Framegröße: Sender kann nicht schneller Pakete schicken
CPU-Last dauerhaft auf 100 % → busy waiting (Delay hätte man einfügen können)
</note>
<note number="15">
das gleiche beim Empfänger
→ hier schon bei ca. 450 Byte Framegröße
CPU-Last eingetragen → Messung mittels "top" → schlägt erst aus, wenn Pakete nicht mehr schnell genug bearbeitet werden können
→ Kern-Prozess "ksoftirq" fast sofort auf 100%
</note>
<note number="16">
eigentliche Messung
bis 25000 Regeln: iptables nach wie vor besser
</note>
<note number="17">
→ nftables besser, was Antwortzeit anbelangt
</note>
<note number="18">
mittlere Regelanzahl → typischer Fall
virtuelle Maschine → sehr leicht neue Erweiterungen machbar
Dokumentation:
bis vor einer Woche: lediglich ein Tutorial verfügbar
jetzt: Wiki mit einigen Beispielen
noch keine vollständige Dokumentation
</note>
</notes>