| 426 | | % TODO: Testen mit iptables! |
| | 426 | |
| | 427 | In den bisherigen Messungen wurde I/O soweit wie möglich eliminiert und |
| | 428 | deshalb ein wichtiger Aufgabenbereich des NF-Knotens außen vor gelassen: |
| | 429 | Die Installation von Policy-Rules auf dem lokalen Knoten durch Verwendung |
| | 430 | von iptables. Wie in Kapitel \ref{ch:Entwurf:sec:Implementierung} |
| | 431 | beschrieben, existiert abgesehen vom iptables-Kommandozeilentool derzeit keine |
| | 432 | offiziell unterstützte Schnittstelle zur Konfiguration des Netfilter-Pakets. |
| | 433 | Für jede einzutragende Policy-Rule muss deshalb ein neuer Prozess gestartet |
| | 434 | werden, was mit hohem Aufwand verbunden ist. |
| | 435 | |
| | 436 | Die folgende Messung ist funktional fast identisch mit der Messung aus |
| | 437 | Tabelle~\ref{tab:nf_3}, nur dass dieses Mal tatsächlich Policy-Rules |
| | 438 | installiert werden. Die Anzahl der Sitzungen (und damit der verarbeiteten |
| | 439 | RESPONSE-Nachrichten) blieb auf 1.000 beschränkt, da der |
| | 440 | iptables-Implementierung im Kernel bereits bei weniger als 10.000 |
| | 441 | eingetragenen Regeln der Speicher ausgeht und danach keine neuen |
| | 442 | Policy Rules mehr angenommen werden. Aber auch so zeigen sich die |
| | 443 | Unterschiede deutlich (siehe Tabelle~\ref{tab:nf_5}). |
| | 444 | |
| | 445 | \begin{table}[h] |
| | 446 | \begin{center} |
| | 447 | \begin{tabular}{|l|r|r|r|r|} |
| | 448 | \hline |
| | 449 | Benchmark & Min & Max & Mean & StdDev \\ |
| | 450 | \hline |
| | 451 | \hline |
| | 452 | Mapping & 18.000 & 84.000 & 24.110 & 3.007 \\ |
| | 453 | Deserialisierung & 11.000 & 30.000 & 15.301 & 1.809 \\ |
| | 454 | Session-Manager & 3.000 & 17.000 & 4.176 & 1.063 \\ |
| | 455 | Protokoll-Automat & 12691.000 & 73946.000 & 42466.151 & 17518.951 \\ |
| | 456 | Serialisierung & 13.000 & 227.000 & 15.272 & 7.002 \\ |
| | 457 | Gesamt & 12725.000 & 73981.000 & 42501.543 & 17519.440 \\ |
| | 458 | \hline |
| | 459 | \end{tabular} |
| | 460 | \caption{Firewall: Eintragen von Policy-Rules mittels iptables (Werte in $\mu s$)} |
| | 461 | \label{tab:nf_5} |
| | 462 | \end{center} |
| | 463 | \end{table} |
| | 464 | |
| | 465 | Gegenüber dem Protokoll-Automaten, der das iptables-Kommando aufruft, ist der |
| | 466 | Zeitverbrauch der anderen Komponenten zu vernachlässigen. Sie bleiben in den |
| | 467 | zuvor beobachteten Größenordnungen, während die Verarbeitungszeit des |
| | 468 | Protokoll-Automaten um mehr als das tausendfache ansteigt. Der Grund für |
| | 469 | die hohe Standardabweichung zeigt Diagramm~\ref{img:nf_iptables}: Die |
| | 470 | Verarbeitungszeit steigt mit der Anzahl der eingetragenen Regeln an. Je |
| | 471 | mehr Policy-Rules bereits eingetragen sind, desto größer wird der Aufwand. |
| | 472 | |
| | 473 | \begin{figure}[h] |
| | 474 | \begin{center} |
| | 475 | \input{nf_iptables} |
| | 476 | \caption{Eintragen von Policy-Rules mittels iptables} |
| | 477 | \label{img:nf_iptables} |
| | 478 | \end{center} |
| | 479 | \end{figure} |
| | 480 | |
| | 481 | Ein Grund dafür ist die Verwaltung der Firewall-Regeln in Form von |
| | 482 | verketteten Listen. Offenbar wird in jedem Fall eine Überprüfung aller |
| | 483 | bisherigen Regeln durchgeführt, egal ob eine neue Regel am Anfang oder |
| | 484 | am Ende der Liste eingefügt werden soll. Während das Eintragen der ersten |
| | 485 | Regel 13 Millisekunden benötigt, schlägt das der tausendsten Regel |
| | 486 | bereits mit mehr als 70ms zu Buche. Die iptables-Implementierung hat |
| | 487 | also durch den iptables-Aufruf bereits sehr hohe Fixkosten und darüber |
| | 488 | hinaus verursacht die Verwaltung der Liste im Kernel linearen Aufwand. |
| | 489 | In dieser Form ist ein Einsatz der NATFW-Implementierung auf NF-Knoten |
| | 490 | mit hohem Verkehrsaufkommen undenkbar. |
| | 491 | |
