[ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ 12 ] [ 13 ] [ 14 ] [ 15 ] [ 16 ] [ 17 ] [ 18 ]

Kapitel 10


Anzahl der Absätze: 343

Project-Id-Version: 0 POT-Creation-Date: 2012-05-09T20:00:20 PO-Revision-Date: 2012-05-09T20:00:20 Last-Translator: Automatically generated Language-Team: None MIME-Version: 1.0 Content-Type: application/x-publican; charset=UTF-8 Content-Transfer-Encoding: 8bit


Netzwerk


Gateway


TCP/IP


IPv6


DNS


Bind


DHCP


QoS


Netzwerk-Infrastruktur


Von Unix hat Linux umfangreiche Netzwerkfunktionalität geerbt. Debian verfügt über alle Werkzeuge, die zum Verwalten von Netzwerken nötig sind. In diesem Kapitel werden diese Werkzeuge besprochen.


Ein Gateway ist ein System, das mehrere Netzwerke verknüpft. Dieser Ausdruck bezieht sich häufig auf den "Ausgang" eines lokalen Netzwerks auf dem vorgeschriebenn Pfad zu allen externen IP-Adressen. Das Gateway ist mit jedem der Netzwerke verbunden, die es verknüpft, und dient als Router zur Übermittlung von IP-Paketen zwischen verschiedenen Schnittstellen.


Gateway


NetzwerkGateway


Router


ZURÜCK ZU DEN GRUNDLAGEN IP Paket


PacketIP


Die meisten Netzwerke nutzen heute das IP Protokoll (Internet Protocol). Dieses Protokoll unterteilt die gesendeten Daten in kleine Packete. Jedes Packet enthält, zusättslich zu den Daten, Details welche benötigt werden für die korrekte Übertragung.


ZURÜCK ZU DEN GRUNDLAGEN TCP/UDP


PortTCP


PortUDP


TCP, port


UDP, port


Viele Programme verarbeiten die individuellen Pakete nicht selbst, auch wenn sie die Daten per IP übertragen. Sie nutzen oft TCP (Transmission Control Protocol/Transport Kontroll Protokoll). TCP ist eine Schicht über IP um Datenströme zwischen zwei Punkten zu ermöglichen. Programme sehen nur einen Eingang in den sie ihre Daten senden können, mit der Garantie das die gleichen Daten ohne verlust(und in der gleichen Reihenfolge) am Ausgang am Ende der Verbindung ankommen. Obwohl viele verschiedene Arten von Fehlern in den unteren Schichten auftreten können regelt das TCP: verlorene Pakete werden nochmals gesendet, Pakete welche in falscher Reihenfolge ankommen(z.B. über verschiedene Pfade) werden in der richtigen Reihenfolge ausgegeben.


Ein weiteres Protokoll welches auf IP aufbaut ist UDP(User Datagram Protocol). Im Gegensatz zu TCP ist es ein Paketorientiert. Es hat andere Aufgaben: es sendet ein Paket von einer Anwendung zu einer Anderen. Das Protokoll kümmert sich dabei nicht um verlorene Pakete oder die Reihenfolge der Pakete. Der Hauptvorteil ist die sehr niedrige Latenz, ein verlorenes Paket hält nicht den Datenstrom auf bis diese wieder übertragen wird.


TCP und UDP nutzen Ports, das sind "Erweiterungs Nummern" um Verbindungen mit einer Anwendung der Maschine herzustellen. Dieses Konzept erlaubt es, mehrere auch verschiedene Verbindungen mit einem Partner aufzubauen, indem man diese Verbindungen über die Port-Nummer unterscheiden kann.


Einige dieser Port-Nummern — standardisiert durch die IANA (Internet Assigned Numbers Authority) — sind "well-known/gut bekannt" wegen der Netzwerk Dienste welche üblicherweise dort laufen. Zum Beispiel TCP Port 25 wir meistens von dem Mail-Server genutzt.


Wenn ein lokales Netzwerk einen privaten Adressbereich verwendet (im Internet nicht erreichbar), muss das Gateway Addressen-Masquerading anwenden, damit die Rechner im Netzwerk mit der Außenwelt kommunizieren können. Das Masquerading ist eine Art Proxy-Verfahren auf Netzwerk-Ebene: jede von einem internen Rechner ausgehende Verbindung wird durch eine Verbindung vom Gateway selbst ersetzt (da das Gateway eine externe, erreichbare Adresse hat), die Daten, die durch die maskierte Verbindung gehen, werden an die neue Adresse gesendet, und die Daten, die als Antwort zurückkommen, werden durch die maskierte Verbindung an den internen Rechner geschickt. Das Gateway verwendet zu diesem Zweck eine Reihe fest zugeordneter TCP-Ports, gewöhnlich mit sehr hohen Nummern (über 60000). Jede von einem internen Rechner kommende Verbindung erscheint der Außenwelt dann so, als käme sie von einem dieser reservierten Ports.


masquerading


CULTURE Privater Addressbereich


IP-Adresseprivat


private IP-Adresse


RFC 1918 definiert drei IPv4-Adressbereiche, die nicht im Internet geroutet werden, sondern nur in lokalen Netzwerken genutzt. Das erste Netz, 10.0.0.0/8 (siehe Seitenleiste ), ist ein Klasse-A Bereich (mit 224 IP-Adressen). Das Zweite, 172.16.0.0/12, enthält 16 Klasse-B Bereiche (172.16.0.0/16 bis 172.31.0.0/16), mit jeweils 216 IP-Adressen. 192.168.0.0/16 ist schließlich ein Klasse-B Bereich (der 256 Klasse-C Bereiche, 192.168.0.0/24 bis 192.168.255.0/24, mit jeweils 256 IP-Adressen zusammenschließt).


Das Gateway kann auch zwei Arten von Network Address Translation (oder kurz NAT genannt) durchführen. Die erste Art, Destination NAT (DNAT), ist ein Verfahren zur Änderung der Ziel-IP-Adresse (oder des TCP- beziehungsweise UDP-Ports) für eine (gewöhnlich) ankommende Verbindung. Der Mechanismus zur Verbindungsverfolgung ändert auch die innerhalb derselben Verbindung nachfolgenden Pakete, um Kontinuität in der Kommunikation sicherzustellen. Die zweite Art des NAT ist Source NAT (SNAT), bei dem das Masquerading ein besonderer Fall ist; SNAT ändert die Ausgangs-IP-Adresse (oder den TCP- beziehungsweise UDP-Port) einer (gewöhnlich) abgehenden Verbindung. Wie beim DNAT werden alle Pakete innerhalb der Verbindung durch den Verbindungsverfolgungsmechanismus sachgerecht behandelt. Beachten Sie, dass NAT nur für IPv4 und seinen begrenzten Adressraum gültig ist; bei IPv6 vermindert die breite Verfügbarkeit von Adressen den Nutzen des NAT in hohem Maße, da es zulässt, dass alle "internen" Adressen direkt ins Internet geleitet werden (dies bedeutet nicht, dass interne Rechner zugänglich sind, da dazwischenliegende Firewalls den Datenverkehr filtern können).


NAT


NetzwerkAddressübersetzung


SNAT


DNAT


Ziel NAT


Quelle NAT


ZURÜCK ZU DEN GRUNDLAGEN Port Weiterleitung


Port-Weiterleitung


Eine konkrete Anwendung von DNAT ist port forwarding. Ankommende Verbindungen eines gegebenen Ports einer Maschine werden zu einem Port einer anderen Maschine weitergeleitet.


Genug der Theorie. Um aus einem Debian-System ein Gateway zu machen, genügt es die passende Option im Linux-Kernel zu aktivieren. Dies geschieht im /proc/ Verzeichnis des Dateisystems.


# echo 1 > /proc/sys/net/ipv4/conf/default/forwarding


Diese Option kann automatisch beim booten gesetzt werden, wenn man in /etc/sysctl.conf die Option net.ipv4.conf.default.forwarding auf 1 setzt.


Die Datei /etc/sysctl.conf


net.ipv4.conf.default.forwarding = 1 net.ipv4.conf.default.rp_filter = 1 net.ipv4.tcp_syncookies = 1


Derselbe Effekt kann für IPv6 durch einfaches Ersetzen von ipv4 durch ipv6 im manuellen Befehl und durch Verwendung der Zeile net.ipv6.conf.all.forwarding in /etc/sysctl.conf erreicht werden.


Das Einstellen des IPv4-Masquerading ist ein etwas komplizierterer Vorgang, der die Konfigurierung der netfilter-Firewall einschließt.


Die Verwendung von NAT (für IPv4) erfordert gleichfalls die Konfigurierung von netfilter. Da der Hauptzweck dieser Komponente im Filtern von Paketen besteht, sind die Einzelheiten in aufgeführt (siehe ).


Virtual Private Network


Ein Virtual Private Network (kurz VPN genannt) ist ein Verfahren, um zwei verschiedene lokale Netze über das Internet mittels eines Tunnels zu verbinden; der Tunnel ist normalerweise zur Wahrung der Vertraulichkeit verschlüsselt. VPNs werden häufig dazu benutzt, einen entfernten Rechner in ein lokales Firmennetz zu integrieren.


networkvirtual private


VPN


virtual private network


Etliche Hilfsprogramme bieten dies an. OpenVPN ist eine effiziente Lösung, die auf SSL/TLS basiert und einfach eingesetzt und verwaltet werden kann. Eine andere Möglichkeit besteht darin, IPsec zu verwenden, um den IP-Verkehr zwischen zwei Rechnern zu verschlüsseln; diese Verschlüsselung ist transparent; das heißt, dass Anwendungen, die auf diesen Arbeitsrechnern laufen, nicht angepasst werden müssen, um das VPN zu berücksichtigen. SSH kann zusätzlich zu seinen gebräuchlicheren Fähigkeiten auch dazu verwendet werden, ein VPN bereitzustellen. Schließlich kann ein VPN auch mithilfe von Microsofts PPTP-Protokoll eingerichtet werden. Es gibt weitere Lösungen, die aber außerhalb des Schwerpunktes dieses Buches liegen.


OpenVPN


OpenVPN


OpenVPN ist eine Software, die dem Erstellen virtueller privater Netze dient. Seine Einrichtung umfasst das Erstellen virtueller Netzwerkschnittstellen auf dem VPN-Server und den Client(s). Sowohl tun (für Tunnel auf IP-Ebene) als auch tap (für Tunnel auf Ethernet-Ebene) werden unterstützt. In der Praxis werden meistens tun-Schnittstellen verwendet, außer wenn die VPN-Clients mittels einer Ethernet-Brücke in das lokale Netz des Servers integriert werden sollen.


OpenVPN ist für die gesamte SSL/TLS-Kryptographie und die damit zusammenhängenden Leistungsmerkmale (Vertraulichkeit, Authentifizierung, Integrität, Nichtabstreitbarkeit) auf OpenSSL angewiesen. Es kann entweder mit einem geteilten privaten Schlüssel oder mithilfe eines X.509-Zertifikats, das auf einer öffentlichen Schlüsselinfrastruktur basiert, konfiguriert werden. Die zweite Konfiguration ist eindeutig vorzuziehen, da sie angesichts einer wachsenden Zahl umherziehender Benutzer, die sich mit dem VPN verbinden, größere Flexibilität ermöglicht,


KULTUR SSL und TLS


SSL


TLS


Das SSL-Protokoll (Secure Socket Layer) wurde von Netscape erfunden, um Verbindungen zu Webservern abzusichern. Es wurde später von IETF unter der Abkürzung TLS (Transport Layer Security) zum Standard erhoben; TLS ist SSLv3 sehr ähnlich mit nur wenigen Korrekturen und Verbesserungen.


Public-Key-Infrastrultur: easy-rsa


PKI (Public-Key-Infrastruktur)


Public-Key-Infrastruktur


X.509, Zertifikat


ZertifikatX.509


easy-rsa


RSA (Algorithmus)


Schlüsselpaar


Der RSA-Algorithmus ist in der Public-Key-Kryptographie weit verbreitet. Er umfasst ein "Schlüsselpaar", das aus einem privaten und einem öffentlichen Schlüssel bezieht. Die beiden Schlüssel sind eng miteinander verbunden, und ihre mathematischen Eigenschaften sind derart, dass eine Nachricht, die mit dem öffentlichen Schlüssel verschlüsselt wurd, nur von jemandem entschlüsselt werden kann, der den privaten Schlüssel kennt, wodurch Vertraulichkeit sichergestellt wird. In umgekehrter Richtung kann eine Nachricht, die mit dem privaten Schlüssel verschlüsselt wurde, von jedem, der den öffentlichen Schlüssel kennt, entschlüsselt werden, was die Authentifizierung des Ursprungs einer Nachricht ermöglicht, da sie nur jemand mit Zugang zum privaten Schlüssel erstellt haben kann. Dies führt in Verbindung mit einer digitalen Hash-Funktion (MD5, SHA1 oder einer neueren Variante) zu einem Signaturverfahren, das auf jede Nachricht angewendet werden kann.


Jedoch kann jeder ein Schlüsselpaar erstellen, eine beliebige Identität auf ihm ablegen und vortäuschen, die Identität seiner Wahl zu sein. Eine Lösung beruht auf dem Konzept einer Certification Authority (CA, Zertifizierungsstelle), das durch den Standard X.509 formalisiert ist. Dieser Begriff bezeichnet eine Organisation, die ein vertrauenswürdiges Schlüsselpaar bereithält, das als Stammzertifikat bezeichnet wird. Dieses Zertifikat wird nur dazu benutzt, andere Zertifikate (Schlüsselpaare) zu signieren, nachdem die erforderlichen Schritte zur Überprüfung der Identität, die auf ihm abgelegt ist, unternommen worden sind. Anwendungen, die X.509 verwenden, können dann die ihnen vorgelegten Zertifikate überprüfen, wenn sie die vertrauenswürdigen Stammzertifikate kennen.


OpenVPN folgt dieser Regel. Da öffentliche Zertifizierungstellen Zertifikate nur gegen eine (hohe) Gebühr ausstellen, ist es auch möglich, eine private Zertifizierungsstelle innerhalb eines Unternehmens einzurichten. Hierfür stellt OpenVPN das Hilfsprogramm easy-rsa bereit, das als Infrastruktur für eine X.509-Zertifizierung dient. Es besteht aus einem Satz von Skripten, die den Befehl openssl verwenden; diese Skripte sind unter /usr/share/doc/openvpn/examples/easy-rsa/2.0/ zu finden.


Die Falcot Corp. Administratoren verwenden dieses Hilfsprogramm, um die erforderlichen Zertifikate sowohl für den Server als auch die Clients zu erstellen. Dies ermöglicht eine ähnlich Konfiguration aller Clients, da sie nur so eingerichtet werden müssen, dass sie Zertifikaten vertrauen, die von Falcots lokaler Zertifizierungsstelle stammen. Für diese Stelle wird das erste Zertifikat erstellt; hierzu kopieren die Administratoren das Verzeichnis, das easy-rsa enthält, an einen passenderen Ort, vorzugsweise auf einen Rechner, der nicht mit dem Netzwerk verbunden ist, um so das Risiko zu verringern, dass der private Schlüssel der Zertifizierungsstelle gestohlen wird.


$ cp -r /usr/share/doc/openvpn/examples/easy-rsa/2.0 pki-falcot $ cd pki-falcot


Sie speichern dann die erforderlichen Parameter in der Datei vars, insbesondere diejenigen, die mit dem Präfix KEY_ versehen sind; diese Variablen werden dann in die Umgebung integriert:


$ vim vars $ grep KEY_ vars export KEY_CONFIG=`$EASY_RSA/whichopensslcnf $EASY_RSA` export KEY_DIR="$EASY_RSA/keys" echo NOTE: If you run ./clean-all, I will be doing a rm -rf on $KEY_DIR export KEY_SIZE=1024 export KEY_EXPIRE=3650 export KEY_COUNTRY="FR" export KEY_PROVINCE="Loire" export KEY_CITY="Saint-Étienne" export KEY_ORG="Falcot Corp" export KEY_EMAIL="admin@falcot.com" $ . ./vars NOTE: If you run ./clean-all, I will be doing a rm -rf on /home/rhertzog/pki-falcot/keys $ ./clean-all


Der nächste Schritt besteht darin, das Schlüsselpaar der Zertifizierungsstelle zu erzeugen (die beiden Teile des Schlüsselpaars werden im Verlauf dieses Schritts unter keys/ca.crt und keys/ca.key gespeichert:


$ ./build-ca Generating a 1024 bit RSA private key ..............................................++++++ .......................++++++ writing new private key to 'ca.key' ----- You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Country Name (2 letter code) [FR]: State or Province Name (full name) [Loire]: Locality Name (eg, city) [Saint-Étienne]: Organization Name (eg, company) [Falcot Corp]: Organizational Unit Name (eg, section) []: Common Name (eg, your name or your server's hostname) [Falcot Corp CA]: Name []: Email Address [admin@falcot.com]:


Jetzt kann das Zertifikat für den VPN-Server erstellt werden, wie auch die Diffie-Hellmann-Parameter, die für die Serverseite einer SSL/TLS-Verbindung benötigt werden. Der VPN-Server ist mit seinem DNS-Namen vpn.falcot.com gekennzeichnet; dieser Name wird für die erzeugten Schlüsseldateien wiederverwendet (keys/vpn.falcot.com.crt für das öffentliche Zertifikat, keys/vpn.falcot.com.key für den privaten Schlüssel):


$ ./build-key-server vpn.falcot.com Generating a 1024 bit RSA private key ...............++++++ ...........++++++ writing new private key to 'vpn.falcot.com.key' ----- You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Country Name (2 letter code) [FR]: State or Province Name (full name) [Loire]: Locality Name (eg, city) [Saint-Étienne]: Organization Name (eg, company) [Falcot Corp]: Organizational Unit Name (eg, section) []: Common Name (eg, your name or your server's hostname) [vpn.falcot.com]: Name []: Email Address [admin@falcot.com]: Please enter the following 'extra' attributes to be sent with your certificate request A challenge password []: An optional company name []: Using configuration from /home/rhertzog/pki-falcot/openssl.cnf Check that the request matches the signature Signature ok The Subject's Distinguished Name is as follows countryName :PRINTABLE:'FR' stateOrProvinceName :PRINTABLE:'Loire' localityName :T61STRING:'Saint-\0xFFFFFFC3\0xFFFFFF89tienne' organizationName :PRINTABLE:'Falcot Corp' commonName :PRINTABLE:'vpn.falcot.com' emailAddress :IA5STRING:'admin@falcot.com' Certificate is to be certified until Oct 9 13:57:42 2020 GMT (3650 days) Sign the certificate? [y/n]:y 1 out of 1 certificate requests certified, commit? [y/n]y Write out database with 1 new entries Data Base Updated $ ./build-dh Generating DH parameters, 1024 bit long safe prime, generator 2 This is going to take a long time ..............+.......+.................................++*++*++*


Der folgende Schritt erstellt Zertifikate für die VPN-Clients; für jeden Rechner oder jede Person, denen es erlaubt ist, das VPN zu nutzen, ist ein eigenes Zertifikate erforderlich:


$ ./build-key JoeSmith Generating a 1024 bit RSA private key ................++++++ .............................++++++ writing new private key to 'JoeSmith.key' ----- You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Country Name (2 letter code) [FR]: State or Province Name (full name) [Loire]: Locality Name (eg, city) [Saint-Étienne]: Organization Name (eg, company) [Falcot Corp]: Organizational Unit Name (eg, section) []: Common Name (eg, your name or your server's hostname) [JoeSmith]:Joe Smith Name []: Email Address [admin@falcot.com]:joe@falcot.com […]


Nachdem nun alle Zertifikate erstellt sind, müssen sie an die passenden Stellen kopiert werden: der öffentliche Schlüssel des Ursprungszertifikats ((keys/ca.crt) wird auf allen Rechnern (sowohl Server als auch Clients) als /etc/ssl/certs/Falcot_CA.crt gespeichert. Das Zertifikat des Servers wird nur auf dem Server installiert (keys/vpn.falcot.com.crt geht nach /etc/ssl/vpn.falcot.com.crt und keys/vpn.falcot.com.key geht nach /etc/ssl/private/vpn.falcot.com.key mit eingeschränkten Berechtigungen, so dass nur der Administrator sie lesen kann), während die entsprechenden Diffie-Hellman-Parameter (keys/dh1024.pem) nach /etc/openvpn/dh1024.pem installiert werden. Die Client-Zertifikate werden in ähnlicher Weise auf den entsprechenden VPN-Clients installiert.


Konfigurieren des OpenVPN-Servers


Standardmäßig versucht das OpenVPN-Initialisierungsskript, alle in /etc/openvpn/*.conf festgelegten virtuellen privaten Netzwerke zu starten. Einen VPN-Server einzurichten besteht daher darin, eine entsprechende Konfigurationsdatei in diesem Verzeichnis abzuspeichern. Ein guter Ausgangspunkt ist /usr/share/doc/openvpn/examples/sample-config-files/server.conf.gz, das zu einem recht standardisierten Server führt. Natürlich müssen einige Parameter angepasst werden: ca, cert, key und dh müssen die ausgewählten Orte bezeichnen (jeweils /etc/ssl/certs/Falcot_CA.crt, /etc/ssl/vpn.falcot.com.crt, /etc/ssl/private/vpn.falcot.com.key und /etc/openvpn/dh1024.pem). Die Anweisung server 10.8.0.0 255.255.255.0 bestimmt das für das VPN zu nutzende Subnetz; der Server belegt die erste IP-Adresse dieses Bereichs (10.8.0.1), während die übrigen Adressen den Clients zugeordnet werden.


Wenn OpenVPN mit dieser Konfiguration gestartet wird, wird die Schnittstelle des virtuellen Netzwerks erstellt, gewöhnlich unter dem Namen tun0. Jedoch werden Firewalls häufig zur gleichen Zeit wie die echten Netzwerkschnittstellen konfiguriert, was vor dem Start von OpenVPN geschieht. Ein bewährtes Verfahren besteht deshalb darin, eine dauerhafte Schnittstelle für das virtuelle Netzwerk einzurichten und OpenVPN so zu konfigurieren, dass es dann diese bereits bestehende Schnittstelle benutzt. Dies macht es auch möglich, einen Namen für diese Schnittstelle auszuwählen. Zu diesem Zweck erstellt der Befehl openvpn --mktun --dev vpn --dev-type tun eine Schnittstelle des virtuellen Netzwerks namens vpn und des Typs tun; dieser Befehl kann leicht in das Konfigurationsskript der Firewall integriert werden oder in eine up-Anweisung der Datei /etc/network/interfaces. Die OpenVPN-Konfigurationsdatei muss ebenfalls in entsprechender Weise mit den Anweisungen dev vpn und dev-type tun aktualisiert werden.


Ohne weitere Maßnahmen können VPN-Clients nur den Server selbst über die Adresse 10.8.0.1 erreichen. Um den Clients Zugang zum lokalen Netzwerk (192.168.0.0/24) zu gewähren, muss die Anweisung push route 192.168.0.0 255.255.255.0 zur OpenVPN-Konfiguration hinzugefügt werden, so dass VPN-Clients automatisch eine Netzwerkroute erhalten, die ihnen sagt, dass dieses Netzwerk über das VPN zu erreichen ist. Darüberhinaus müssen Rechner im lokalen Netzwerk ebenfalls darüber informiert werden, dass der Weg zum VPN über den VPN-Server verläuft (dies funktioniert automatisch, wenn der VPN-Server auf dem Gateway installiert ist). Alternativ kann der VPN-Server auch dafür konfiguriert werden, IP-Masquerading auszuüben, so dass Verbindungen, die von den VPN-Clients kommen, so aussehen, als kämen sie stattdessen vom VPN-Server (siehe ).


Konfigurieren des OpenVPN-Clients


Das Einrichten eines OpenVPN-Clients erfordert auch das Erstellen einer Konfigurationsdatei in /etc/openvpn/. Eine Standard-Konfigurierung kann durch Verwendung der Datei /usr/share/doc/openvpn/examples/sample-config-files/client.conf als Ausgangspunkt erzielt werden. Die Anweisung remote vpn.falcot.com 1194 bezeichnet die Adresse und den Port des OpenVPN-Servers; ca, cert und key müssen auch angepasst werden, so dass sie die Orte der Schlüsseldateien bezeichnen.


Falls das VPN beim Hochfahren nicht automatisch starten soll, setzen Sie die AUTOSTART-Anweisung in der Datei /etc/default/openvpn auf none. Das Starten oder Anhalten einer bestimmten VPN-Verbindung ist immer mit den Befehlen /etc/init.d/openpvn start name und /etc/init.d/openpvn stop name möglich (wobei die Verbindung name mit derjenigen übereinstimmen muss, die in /etc/openvpn/name.conf eingetragen ist.


Das Paket network-manager-openvpn-gnome enthält eine Erweiterung für Network Manager (siehe ), die es ermöglicht, OpenVPN-Netzwerke zu verwalten. Sie ermöglicht es jedem Benutzer, OpenVPN-Verbindungen grafisch zu konfigurieren und sie über das Netzwerkverwaltungs-Symbol zu kontrollieren.


Virtual Private Network mit SSH


SSH


PPP


Es gibt eigentlich zwei Wege, um ein virtuelles privates Netzwerk mit SSH zu erstellen. Der historische erfordert die Einrichtung einer PPP-Schicht über die SSH-Verbindung. Diese Methode wird in einem HOWTO-Dokument beschrieben:


Die zweite Methode ist neueren Datums und wurde mit OpenSSH 4.3 eingeführt; OpenSSH kann jetzt Schnittstellen des virtuellen Netzwerks (tun*) auf beiden Seiten einer SSH-Verbindung erstellen, und diese virtuellen Schnittstellen können genauso konfiguriert werden, als seien es reale Schnittstellen. Das Tunnelungssystem muss zuvor aktivitiert werden, indem PermitTunnel in der Konfigurationsdatei des SSH-Servers (/etc/ssh/sshd_config) auf "yes" gesetzt wird. Bei der Einrichtung der SSH-Verbindung muss die Erstellung eines Tunnels ausdrücklich mit der Option -w any:any verlangt werden (any kann durch die gewünschte tun-Gerätenummer ersetzt werden). Hierzu benötigt der Benutzer Administratorrechte auf beiden Seiten, um so das Netzwerkgerät erstellen zu können (mit anderen Worten: die Verbindung muss als Root eingerichtet werden).


Beide Methoden zur Erstellung eines virtuellen privaten Netzwerks über SSH sind recht einfach. Jedoch ist das VPN, das sie bereitstellen, nicht das effizienteste; insbesondere kann es nicht gut mit starkem Datenverkehr umgehen.


Die Erklärung ist, dass das TCP-Protokoll zweimal verwendet wird, wenn ein TCP/IP-Stack in einer TCP/IP-Verbindung (für SSH) eingekapselt ist, einmal für die SSH-Verbindung und einmal innerhalb des Tunnels. Dies führt zu Problemen, insbesondere wegen der Art, in der TCP sich an Netzwerkbedingungen anpasst, indem es Zeitüberschreitungsverzögerungen ändert. Die folgende Seite beschreibt das Problem genauer: VPNs über SSH sollten daher auf einmalige Tunnel ohne Leistungserfordernisse beschränkt bleiben.


IPsec


IPsec


openswan


strongswan


racoon


Obwohl IPsec der Standard in IP-VPNs ist, ist es stärker an seiner Umsetzung beteiligt. Die IPsec-Engine selbst ist im Linux-Kernel integriert; die erforderlichen Teile des Benutzerraums sowie die Steuerungs- und Konfigurierungsprogramme werden vom Paket ipsec-tools bereitgestellt. Konkret enthält die Datei /etc/ipsec-tools.conf jedes Rechners die Parameter für die IPsec-Tunnel (oder in der IPsec-Terminologie: Security Associations), mit denen der Rechner zu tun hat; das Skript /etc/init.d/setkey bietet die Möglichkeit, einen Tunnel zu eröffnen oder zu schließen (jeder Tunnel ist eine sichere Verbindung zu einem anderen mit dem virtuellen privaten Netzwerk verbundenen Rechner). Diese Datei kann von Hand mithilfe der Dokumentation auf der Handbuchseite setkey 8 erstellt werden. Es wird jedoch schnell zu einer mühseligen Arbeit, die Parameter aller Rechner in einem nicht alltäglichen Satz von Geräten ausführlich niederzuschreiben, da die Anzahl der Tunnel schnell ansteigt. Die Installation eines IKE-Daemons (für IPsec Key Exchange), wie racoon, strongswan oder openswan, macht den Vorgang wesentlich einfacher durch das Bündeln der Verwaltung an einem zentralen Punkt und sicherer durch das regelmäßige Rotieren der Schlüssel. IKE IPsecIPsec Key Exchange Schlüsselpaar setkey


Trotz seines Status als Referenz, schränkt die Komplexität der Einrichtung von IPsec seine Verwendung in der Praxis ein. Lösungen auf der Basis von OpenVPN werden im allgemeinen bevorzugt, solange die erforderlichen Tunnel weder zu zahlreich noch zu dynamisch sind.


VORSICHT IPsec und NAT


Firewalls mit NAT und IPsec arbeiten nicht gut zusammen: da IPsec die Pakete signiert, macht jede Veränderung dieser Pakete, die die Firewall möglicherweise vornimmt, die Signatur ungültig, und die Pakete werden an ihrem Ziel zurückgewiesen. Mehrere IPsec-Anwendungen enthalten inzwischen die NAT-T-Technik (für NAT Traversal), die im Prinzip das IPsec-Paket in einem normalen UDP-Pakets einkapselt.


NAT-T


NAT Traversal


SICHERHEIT IPsec und Firewalls


Die normale Arbeitsweise von IPsec umfasst den Datenaustausch auf dem UDP-Port 500 für den Austausch von Schlüsseln (auch auf UDP-Port 4500, falls NAT-T benutzt wird). Darüberhinaus benutzen IPsec-Pakete zwei fest zugeordnete IP-Protokolle, die die Firewall durchlassen muss; der Empfang dieser Pakete basiert auf ihren Protokollnummern 50 (ESP) und 51 (AH).


ESP, protocol


AH, protocol


protocolAH


protocolESP


PPTP


PPTP (für Point-to-Point Tunneling Protocol) verwendet zwei Kommunikationskanäle, einen für die Kontrolldaten und einen für die Nutzdaten; letzterer verwendet das GRE-Protokoll (Generic Routing Encapsulation). Eine Standard-PPP-Verbindung wird dann über den Datenaustauschkanal eingerichtet.


PPTP


Point-to-Point Tunneling Protokoll


GRE, Protokoll


ProtokollGRE


Den Client konfigurieren


Das Paket pptp-linux enthält einen leicht zu konfigurierenden PPTP-Client für Linux. Die folgenden Anweisungen beziehen ihre Anregungen aus der offiziellen Dokumentation:


pptp-linux


Die Falcot-Administratoren haben mehrere Dateien erstellt: /etc/ppp/options.pptp, /etc/ppp/peers/falcot, /etc/ppp/ip-up.d/falcot und /etc/ppp/ip-down.d/falcot.


Die Datei /etc/ppp/options.pptp


# PPP options used for a PPTP connection lock noauth nobsdcomp nodeflate


Die Datei /etc/ppp/peers/falcot


# vpn.falcot.com is the PPTP server pty "pptp vpn.falcot.com --nolaunchpppd" # the connection will identify as the "vpn" user user vpn remotename pptp # encryption is needed require-mppe-128 file /etc/ppp/options.pptp ipparam falcot


Die Datei /etc/ppp/ip-up.d/falcot


# Create the route to the Falcot network if [ "$6" = "falcot" ]; then # 192.168.0.0/24 is the (remote) Falcot network route add -net 192.168.0.0 netmask 255.255.255.0 dev $1 fi


Die Datei /etc/ppp/ip-down.d/falcot


# Delete the route to the Falcot network if [ "$6" = "falcot" ]; then # 192.168.0.0/24 is the (remote) Falcot network route del -net 192.168.0.0 netmask 255.255.255.0 dev $1 fi


SICHERHEIT MPPE


Das Absichern von PPTP erfolgt mithilfe der MPPE-Funktion (Microsoft Point-to-Point Encryption), die in den offiziellen Debian-Kerneln als Modul vorhanden ist.


MPPE


MicrosoftPoint-to-Point Verschlüsselung


Den Server konfigurieren


VORSICHT PPTP und Firewalls


Zwischenliegende Firewalls müssen so konfiguriert sein, dass sie IP-Pakete, die das Protokoll 47 (GRE) verwenden, durchlassen. Außerdem muss der Port 1723 des PPTP-Servers geöffnet sein, damit der Kommunikationskanal stattfinden kann.


pptpd ist der PPTP-Server für Linux. Seine Hauptkonfiguratiosdatei, /etc/pptpd.conf, erfordert nur sehr wenige Änderungen: localip (die lokale IP-Adresse) und remoteip (die entfernte IP-Adresse). Im folgenden Beispiel benutzt der PPTP-Server stets die Adresse 192.168.0.199, und PPTP-Clients erhalten Adressen von 192.168.0.200 bis 192.168.0.250.


Die Datei /etc/pptpd.conf


# TAG: speed # # Specifies the speed for the PPP daemon to talk at. # speed 115200 # TAG: option # # Specifies the location of the PPP options file. # By default PPP looks in '/etc/ppp/options' # option /etc/ppp/pptpd-options # TAG: debug # # Turns on (more) debugging to syslog # # debug # TAG: localip # TAG: remoteip # # Specifies the local and remote IP address ranges. # # You can specify single IP addresses seperated by commas or you can # specify ranges, or both. For example: # # 192.168.0.234,192.168.0.245-249,192.168.0.254 # # IMPORTANT RESTRICTIONS: # # 1. No spaces are permitted between commas or within addresses. # # 2. If you give more IP addresses than MAX_CONNECTIONS, it will # start at the beginning of the list and go until it gets # MAX_CONNECTIONS IPs. Others will be ignored. # # 3. No shortcuts in ranges! ie. 234-8 does not mean 234 to 238, # you must type 234-238 if you mean this. # # 4. If you give a single localIP, that's ok - all local IPs will # be set to the given one. You MUST still give at least one remote # IP for each simultaneous client. # #localip 192.168.0.234-238,192.168.0.245 #remoteip 192.168.1.234-238,192.168.1.245 #localip 10.0.1.1 #remoteip 10.0.1.2-100 localip 192.168.0.199 remoteip 192.168.0.200-250


Die vom PPTP-Server verwendete PPP-Konfiguration erfordert auch einige Änderungen in /etc/ppp/pptpd-options. Die wichtigen Parameter sind der Servername (pptp), der Domainname (falcot.com) und die IP-Adressen für DNS- und WINS-Server.


Die Datei /etc/ppp/pptpd-options


## turn pppd syslog debugging on #debug ## change 'servername' to whatever you specify as your server name in chap-secrets name pptp ## change the domainname to your local domain domain falcot.com ## these are reasonable defaults for WinXXXX clients ## for the security related settings # The Debian pppd package now supports both MSCHAP and MPPE, so enable them # here. Please note that the kernel support for MPPE must also be present! auth require-chap require-mschap require-mschap-v2 require-mppe-128 ## Fill in your addresses ms-dns 192.168.0.1 ms-wins 192.168.0.1 ## Fill in your netmask netmask 255.255.255.0 ## some defaults nodefaultroute proxyarp lock


Der letzte Schritt besteht in der Registrierung des vpn-Benutzers (und des dazugehörigen Passworts) in der Datei /etc/ppp/chap-secrets. Im Gegensatz zu anderen Fällen, in denen ein Stern (*) funktionieren würde, muss hier der Servername ausdrücklich angegeben werden. Außerdem identifizieren sich Windows-PPTP-Clients in der Form DOMAIN\\BENUTZER statt nur einen Benutzernamen anzugeben. Dies erklärt, warum die Datei auch den Benutzer FALCOT\\vpn erwähnt. Es ist auch möglich, individuelle IP-Adressen für Benutzer anzugeben; ein Stern in diesem Feld bedeutet, dass eine dynamische Adressierung verwendet werden soll.


Die Datei /etc/ppp/chap-secrets


# Secrets for authentication using CHAP # client server secret IP addresses vpn pptp f@Lc3au * FALCOT\\vpn pptp f@Lc3au *


SICHERHEIT PPTP-Schwachstellen


Microsofts erste PPTP-Anwendung hat heftige Kritik auf sich gezogen, da sie viele Sicherheitsschwachstellen hatte; die meisten sind seither in neueren Versionen behoben worden. Die in diesem Abschnitte beschriebene Konfigurierung verwendet die jüngste Version des Protokolls. Seien Sie sich jedoch bewusst, dass das Entfernen einiger Optionen (wie require-mppe-128 und require-mschap-v2) den Dienst wieder angreifbar machen würde.


Quality of Service


Prinzip und Mechanismus


Quality of Service (oder kurz QoS) bezieht sich auf eine Reihe von Techniken, die die Qualität der Dienste, die den Anwendungen bereitgestellt werden, sicherstellen oder verbessern. Die populärste derartige Technik betrifft die Einstufung des Netzverkehrs in Kategorien und die Differenzierung der Abwicklung des Datenverkehrs je nach der Kategorie, zu der er gehört. Die Hauptanwendung dieses differenzierten Dienstekonzepts ist traffic shaping, das die Datenübertragungsraten für Verbindungen im Zusammenhang mit einigen Diensten oder Rechnern begrenzt, um nicht die verfügbare Bandbreite auszuschöpfen und wichtige andere Dienste auszubremsen. Traffic Shaping passt besonders gut zum TCP-Datenverkehr, da sich dieses Protokoll automatisch auf die verfügbare Bandbreite einstellt.


QoS


quality of service


qualityof service


servicequality


Es ist auch möglich die Prioritäten für den Datenverkehr zu ändern, wodurch Pakete in Verbindung mit interaktiven Diensten (wie ssh und telnet) oder mit Diensten, die nur mit kleinen Datenblöcken umgehen, bevorzugt werden.


Die Debian-Kernel enthalten die für QoS erforderlichen Funktionen zusammen mit ihren dazugehörigen Modulen. Diese Module sind zahlreich, und jedes von ihnen stellt einen anderen Dienst bereit, vor allem mittels spezieller Steuerprogramme für die Warteschlangen der IP-Pakete; die große Vielfalt der Verhaltensweisen der verfügbaren Steuerprogramme deckt den gesamten Bereich möglicher Anforderungen ab.


KULTUR LARTC — Linux Advanced Routing & Traffic Control


Das HOWTO Linux Advanced Routing & Traffic Control ist das Referenzdokument, das alles behandelt, was man zum Thema Quality of Service von Netzwerken wissen möchte.


Routingverbessertes


Kontrolle des Datenverkehrs


Kontrolle, des Datenverkehrs


Konfigurieren und Ausführen


QoS-Parameter werden mit dem Befehl tc gesetzt (vom Paket iproute bereitgestellt). Da diese Schnittstelle recht komplex ist, ist die Verwendung von Programmen auf höherer Ebene empfehlenswert.


iproute


tc


Latenzzeiten verringern: wondershaper


Die Hauptaufgabe von wondershaper (in dem Paket ähnlichen Namens) besteht darin, Latenzzeiten unabhängig von der Netzauslastung zu minimieren. Dies wird dadurch erreicht, dass der gesamte Datenverkehr auf einen Wert begrenzt wird, der gerade unterhalb des Wertes für die vollständige Auslastung der Verbindung liegt.


wondershaper


Begrenzung, des Datenverkehrs


DatenverkehrBegrenzung


Sobald eine Netzwerkschnittstelle konfiguriert ist, wird das Einstellen der Datenverkehrsbegrenzung durch das Ausführen von wondershaper schnittstelle download_rate upload_rate erreicht. Die Schnittstelle kann zum Beispiel eth0 oder ppp0 sein, und beide Raten werden in Kilobits pro Sekunde ausgedrückt. Der Befehl wondershaper remove schnittstelle unterbindet die Datenverkehrskontrolle an der genannten Schnittstelle.


Für eine Ethernetverbindung wird dieses Skript am besten unmittelbar nach der Konfigurierung der Schnittstelle aufgerufen. Dies geschieht, indem up- und down-Anweisungen zur Datei /etc/network/interfaces hinzugefügt werden, die es den angegebenen Befehlen erlauben zu laufen, nachdem die Schnittstelle konfiguriert beziehungsweise bevor sie dekonfiguriert wird. Zum Beispiel:


Änderungen in der Datei /etc/network/interfaces


iface eth0 inet dhcp up /sbin/wondershaper eth0 500 100 down /sbin/wondershaper remove eth0


Im Falle von PPP aktiviert ein Skript, das wondershaper in /etc/ppp/ip-up.d/ aufruft, die Datenverkehrskontrolle, sobald die Verbindung steht.


WEITERE SCHRITTE Optimale Konfiguration


Die Datei /usr/share/doc/wondershaper/README.Debian.gz beschreibt recht genau die vom Paketbetreuer empfohlene Konfigurierungsmethode. Insbesondere rät es dazu, die Upload- und Downloadgeschwindigkeit zu messen, um so am besten die tatsächlichen Grenzen abzuschätzen.


Standard-Konfiguration


Falls es keine besondere QoS-Konfigurierung gibt, verwendet der Linux-Kernel das Warteschlangen-Steuerprogramm pfifo_fast, das selbst einige interessante Funktionen aufweist. Die Priorität jedes verarbeiteten IP-Pakets hängt von dem ToS-Feld (Type of Service) dieses Pakets ab; es genügt, dieses Feld zu ändern, um die zeitlichen Steuerungsfunktionen zu nutzen. Es gibt fünf mögliche Werte:


Normal-Service (0);


Minimize-Cost (2);


Maximize-Reliability (4);


Maximize-Throughput (8);


Minimize-Delay (16).


ToS


Type of Service


Das ToS-Feld kann durch Anwendungen, die IP-Pakete erzeugen, erstellt oder im laufenden Betrieb mit netfilter verändert werden. Die folgenden Regeln genügen, um die Ansprechbarkeit des SSH-Dienstes eines Servers zu erhöhen:


iptables -t mangle -A PREROUTING -p tcp --sport ssh -j TOS --set-tos Minimize-Delay iptables -t mangle -A PREROUTING -p tcp --dport ssh -j TOS --set-tos Minimize-Delay


Dynamisches Routing


Routingdynamisches


quagga


zebra


Das Referenzprogramm für das dynamische Routing ist zur Zeit quagga, aus dem Paket ähnlichen Namens; früher war es zebra, bis seine Entwicklung eingestellt wurde. Jedoch führte quagga die Bezeichnungen der Programme aus Kompatibilitätsgründen vor, wodurch sich die untenstehenden zebra-Befehle erklären.


ZURÜCK ZU DEN GRUNDLAGEN Dynamisches Routing


Dynamisches Routing ermöglicht es Routern, die zur Übertragung von IP-Paketen verwendeten Pfade in Echtzeit anzupassen. Jedes Protokoll benutzt seine eigene Methode, um Routen festzulegen (kürzester Weg, von anderen Teilnehmern empfohlene Routen und so weiter).


Im Linux-Kernel verbindet eine Route ein Netzwerkgerät mit einer Reihe von Rechnern, die über dieses Gerät erreicht werden können. Der Befehl route legt neue Routen fest und zeigt bestehende an.


zebra


Quagga ist ein Satz von Daemons, die bei der Festlegung der Routingtabellen zur Verwendung durch den Linux-Kernel zusammenarbeiten; jedes Routingprotokoll (insbesondere BGP, OSPF und RIP) stellt seinen eigene Daemon bereit. Der zebra-Daemon sammelt Informationen von anderen Daemons und verarbeitet statische Routingtabellen dementsprechend. Die übrigen Daemons sind bekannt als bgpd, ospfd, ospf6d, ripd und ripngd.


OSPF


BGP


RIP


bgpd


ospfd


ospf6d


ripd


ripngd


Daemons werden durch Editieren der Datei /etc/quagga/daemons und Erstellen der entsprechenden Konfigurationsdatei in /etc/quagga/ aktiviert; diese Konfigurationsdatei muss nach dem Daemon benannt sein, mit der Erweiterung .conf, und dem quagga-Benutzer und der quaggavty-Gruppe gehören, damit das Skript /etc/init.d/quagga den Daemon aufruft.


Zur Konfigurierung jedes dieser Daemons ist es erforderlich, das betreffende Routingprotokoll zu kennen. Diese Protokolle können hier nicht im Einzelnen beschrieben werden, jedoch stellt quagga-doc umfangreiche Erläuterungen in Form einer info-Datei bereit. Der gleiche Stoff kann auch leichter als HTML auf der Quagga-Webseite durchsucht werden: Außerdem ist die Syntax der Konfigurationsschnittstelle eines Standard-Routers sehr ähnlich, und Netzwerk-Administratoren werden sich schnell an quagga gewöhnen.


IN DER PRAXIS OSPF, BGP or RIP?


OSPF ist im Allgemeinen das beste Protokoll für das dynamische Routing auf privaten Netzwerken, während BGP für das Internet-weite Routing üblicher ist. RIP ist recht alt und wird nur noch selten verwendet.


IPv6, der Nachfolger von IPv4, ist eine neue Version des IP-Protokolls, das mit dem Ziel entwickelt wurde, seine Schwächen zu beheben, vor allem die Knappheit verfügbarer IP-Adressen. Dieses Protokoll handhabt die Netzwerkschichten; es dient dazu, eine Möglichkeit zur Adressierung von Rechnern bereitzustellen, Daten an ihr vorgesehenes Ziel zu übertragen und falls erforderlich die Datenfragmentierung zu erledigen (mit anderen Worten, Pakete in Stücke aufzuteilen, deren Größe von den Netzwerkverbindungen abhängen, die unterwegs benutzt werden, und diese Stücke bei der Ankunft wieder in ihrer richtigen Reihenfolge zusammenzusetzen).


Debian-Kernel enthalten IPv6-Behandlung im Core-Kernel (was nicht immer der Fall war; das ipv6-Modul war früher optional). Grundlegende Programme wie ping und traceroute haben ihre IPv6-Äquivalente in Form von ping6 und traceroute6, die in den Paketen iputils-ping beziehungsweise iputils-tracepath verfügbar sind.


IPv6


iputils-ping


iputils-tracepath


Das IPv6-Netzwerk ist in ähnlicher Weise wie IPv4 konfiguriert in /etc/network/interfaces. Wenn jedoch dieses Netzwerk global verfügbar sein soll, müssen Sie sicherstellen, dass sie einen IPv6-fähigen Router haben, um den Datenverkehr an das weltweite IPv6-Netzwerk zu übermitteln.


KULTUR Das 6Bone


6Bone


Während der experimentellen Phase des IPv6-Protokolls wurde eine globale Netzwerkinfrastruktur eingerichtet, um das Testen des neuen Protokolls zu erleichtern. Dieses Netzwerk war bekannt als das 6Bone, eine Zusammenziehung aus der 6 in IPv6 und dem Begriff network backbone. Dieses 6Bone verschwand offiziell am 6. Juni 2006 (beachten Sie die Allgegenwart der Zahl 6), aber der Spitzname wird weiterhin benutzt, um sich auf den Teil des Internets zu beziehen, der mit IPv6 umgehen kann.


Beispiel einer IPv6-Konfiguration


iface eth0 inet6 static address 3ffe:ffff:1234:5::1:1 netmask 64 # Disabling auto-configuration # up echo 0 >/proc/sys/net/ipv6/conf/all/autoconf # The router is auto-configured and has no fixed address # (/proc/sys/net/ipv6/conf/all/accept_ra). If it had: # gateway 3ffe:ffff:1234:5::1


Falls keine native IPv6-Verbindung verfügbar ist, besteht eine Ausweichmöglichkeit darin, einen Tunnel über IPv4 zu verwenden. Freenet6 ist ein (freier) Anbieter solcher Tunnel:


Freenet6


Um einen Freenet6-Tunnel verwenden zu können, müssen Sie sich auf der Webseite registrieren, dann das Paket tspc installieren und den Tunnel konfigurieren. Hierzu muss die Datei /etc/tsp/tspc.conf editiert werden: die Zeilen userid und password, die Sie per E-Mail erhalten, sollten hinzugefügt und server durch broker.freenet6.net ersetzt werden.


IPv6-Konnektivität wird allen Rechnern eines lokalen Netzes durch das Hinzufügen der folgenden drei Anweisungen zu der Datei /etc/tsp/tspc.conf angeboten (unter der Annahme, dass das lokale Netz mit der eth0-Schnittstelle verbunden ist):


host_type=router prefix_len=48 if_prefix=eth0


Der Rechner wird hiermit zum Zugangsrouter für ein Subnetz mit einem 48-Bit-Präfix. Sobald der Tunnel diese Veränderung wahrnimmt, muss das lokale Netzwerk hierüber informiert werden; dies bedeutet, dass der radvd-Daemon installiert werden muss (aus dem Paket ähnlichen Namens). Dieser IPv6-Konfigurierungsdaemon hat eine ähnliche Rolle wie dhcpd in der IPv4-Welt.


Anschließend muss die Konfigurationsdatei /etc/radvd.conf erstellt werden (siehe /usr/share/doc/radvd/examples/simple-radvd.conf als Ausgangspunkt). In unserem Fall ist es nur erforderlich, das Präfix zu verändern, das durch das von Freenet6 bereitgestellte ersetzt werden muss; es ist in der Ausgabe des Befehls ifconfig zu finden im Absatz zur tun-Schnittstelle.


radvd


Dann führen Sie /etc/init.d/tspc restart und /etc/init.d/radvd start aus, und das IPv6-Netzwerk sollte funktionieren.


TIP Programme mit IPv6-Unterstützung


Viele Computerprogramme müssen angepasst werden, damit sie mit IPv6 umgehen können. Die meisten Pakete in Debian Squeeze sind bereits angepasst, jedoch nicht alle. Einige Freiwillige hatten ehemals ein Paketarchiv eingerichtet, das Programmen gewidmet war, die speziell für IPv6 umgeschrieben worden waren; dieses Archiv wurde im März 2007 stillgelegt, sowohl aus Zeitmangel als auch aus Mangel an Interesse (da die meisten Patches in die offiziellen Pakete integriert worden waren). Falls Ihr bevorzugtes Paket noch nicht mit IPv6 funktioniert, können Sie auf der folgenden Mailingliste Hilfe finden: debian-ipv6 mailing-list.


VORSICHT IPv6 und Firewalls


IPv6 Firewall


FirewallIPv6


ip6tables


Natives IPv6 erfordert (im Gegensatz zu einem Tunnel über IPv4), dass die Firewall Datenverkehr akzeptiert, der die IP-Protokollnummer 41 benutzt. Verbindungen können weiterhin, wie unter IPv4, beschränkt werden: die Debian Standardkernel enthalten eine Anpassung von netfilter an IPv6. Dieses IPv6-fähige netfilter ist auf ähnliche Weise wie sein IPv4-Pendant konfiguriert, nur dass das zu verwendende Programm ip6tables statt iptables ist.


Domain Name Server (DNS)


DNS


ServerName


Der Domain Name Service (DNS) ist ein grundlegender Bestandteil des Internets: Er löst Rechnernamen in IP-Adressen auf (und umgekehrt), wodurch es möglich ist, www.debian.org statt 82.195.75.97 zu verwenden.


DNS-Einträge sind in Zonen gegliedert; jede Zone entspricht einer Domain (oder Subdomain) oder einem Bereich von IP-Adressen (da IP-Adressen normalerweise in fortlaufenden Bereichen angeordnet sind). Ein Hauptserver ist für den Inhalt einer Zone zuständig; untergeordnete Server, die normalerweise auf separaten Rechnern untergebracht sind, stellen regelmäßig aktualisierte Kopien der Hauptzone bereit.


ZoneDNS


DNSZone


Jede Zone enthält Aufzeichnungen verschiedener Art (Resource Records):


A: IPv4-Adresse. A, DNS-Eintrag


CNAME: Alias (canonical name). CNAME, DNS record


MX: mail exchange, ein E-Mailserver. Diese Information wird von anderen E-Mailservern dazu benutzt herauszufinden, wohin an eine bestimmte Adresse gerichtete E-Mail geschickt werden soll. Jeder MX-Eintrag hat eine bestimmte Priorität. Zunächst wird ein Versuch beim Server mit der höchsten Priorität (mit der niedrigsten Nummer) unternommen (siehe Seitenleiste ); andere Server werden nach abnehmender Priorität kontaktiert, falls der erste nicht antwortet. MXDNS-Eintrag


PTR: Namenszuordnung zu einer IP-Adresse. Ein derartiger Eintrag ist in einer "reverse-DNS"-Zone gespeichert, die nach dem IP-Adressbereich benannt ist. Zum Beispiel ist 1.168.192.in-addr.arpa die Zone, die die umgekehrten Zuordnungen aller Adressen im Bereich 192.168.1.0/24 enthält. PTR, DNS-Eintrag


AAAA: IPv6-Adresse. AAAA, DNS-Eintrag


NS: ordnet einen Namen einem Namensserver zu. Jede Domain muss wenigstens einen NS-Eintrag haben. Diese Einträge verweisen auf einen DNS-Server, der Anfragen beantworten kann, die diese Domain betreffen; sie verweisen gewöhnlich auf die primären und sekundären Server für diese Domain. Diese Einträge erlauben auch eine DNS-Delegierung; zum Beispiel kann die Zone falcot.com einen NS-Eintrag für internal.falcot.com enthalten, was bedeutet, dass die Zone internal.falcot.com von einem anderen Server gehandhabt wird. Natürlich muss dieser Server dann eine internal.falcot.com-Zone festlegen. NS, DNS-Eintrag


EintragDNS DNS-Eintrag


Der Referenz-Namensserver Bind wurde vom ISC (Internet Software Consortium) entwickelt und wird von ihm betreut. Er wird in Debian durch das Paket bind9 bereitgestellt. Version 9 weist im Vergleich zu früheren Versionen zwei größere Veränderungen auf. Zum einen kann der DNS-Server jetzt unter einem nicht previligierten Benutzer laufen, so dass ein Angreifer durch eine Sicherheitslücke im Server keine Administratorrechte erlangen kann (wie bei den Versionen 8.x häufiger geschehen).


Zum anderen unterstützt Bind den DNSSEC-Standard zum Signieren (und damit Authentifizieren) von DNS-Einträgen, wodurch es möglich ist, jegliches Spoofing dieser Daten durch einen Man-In-The-Middle-Angriff zu unterbinden.


bind9


ISC


Internet Software Consortium


KULTUR DNSSEC


DNSSEC


Die DNSSEC-Norm ist recht komplex; dies erklärt zum Teil, warum seine Verwendung noch nicht weitverbreitet ist (obwohl es ohne weiteres neben DNS-Servern bestehen kann, die das DNSSEC nicht bemerken). Um alle Einzelheiten zu verstehen, sollten Sie einen Blick in den folgenden Artikel werfen.


Konfigurieren


Konfigurationsdateien für bind haben unabhängig von der Version die gleiche Struktur.


Die Falcot-Administratoren erstellen eine primäre falcot.com-Zone, um dort Informationen, die sich auf diese Domain beziehen, abzulegen und eine 168.192.in-addr.arpa-Zone für die umgekehrte Namenszuordnung von IP-Adressen in den lokalen Netzen.


VORSICHT Bezeichnung umgekehrter Zonen


zonereverse


reverse zone


in-addr.arpa


Umgekehrte Zonen habe eine besondere Bezeichnung. Die Zone, die das Netzwerk 192.168.0.0/16 erfasst, muss 168.192.in-addr.arpa heißen: die IP-Adresskomponenten sind umgekehrt und gefolgt vom Suffix in-addr.arpa.


TIP Den DNS-Server testen


Der Befehl host (im Paket bind9-host) fragt bei einem DNS-Server an und kann dazu benutzt werden, die Serverkonfiguration zu testen. Zum Beispiel überprüft der Befehl host machine.falcot.com localhost die Antwort des lokalen Servers auf eine Anfrage nach machine.falcot.com. Der Befehl host ipaddress localhost überprüft die umgekehrte Namensauflösung.


host


Die folgenden Konfigurationsauszüge sind den Falcot-Dateien entnommen und können als Ausgangspunkt für das Konfigurieren eines DNS-Servers dienen:


named.conf


/etc/bind/named.conf


Auszug aus der Datei /etc/bind/named.conf.local


zone "falcot.com" { type master; file "/etc/bind/db.falcot.com"; allow-query { any; }; allow-transfer { 195.20.105.149/32 ; // ns0.xname.org 193.23.158.13/32 ; // ns1.xname.org }; }; zone "internal.falcot.com" { type master; file "/etc/bind/db.internal.falcot.com"; allow-query { 192.168.0.0/16; }; }; zone "168.192.in-addr.arpa" { type master; file "/etc/bind/db.192.168"; allow-query { 192.168.0.0/16; }; };


Auszug aus der Datei /etc/bind/db.falcot.com


; falcot.com Zone ; admin.falcot.com. => zone contact: admin@falcot.com $TTL 604800 @ IN SOA falcot.com. admin.falcot.com. ( 20040121 ; Serial 604800 ; Refresh 86400 ; Retry 2419200 ; Expire 604800 ) ; Negative Cache TTL ; ; The @ refers to the zone name ("falcot.com" here) ; or to $ORIGIN if that directive has been used ; @ IN NS ns @ IN NS ns0.xname.org. interne IN NS 192.168.0.2 @ IN A 212.94.201.10 @ IN MX 5 mail @ IN MX 10 mail2 ns IN A 212.94.201.10 mail IN A 212.94.201.10 mail2 IN A 212.94.201.11 www IN A 212.94.201.11 dns IN CNAME ns


VORSICHT Namenssyntax


Die Syntax eines Rechnernamens folgt strengen Regeln. Zum Beispiel: rechner bedeutet rechner.domain. Falls die Bezeichnung der Domain nicht an einen Namen angehängt sein soll, muss der betreffende Name als rechner. geschrieben werden (mit einem Punkt als Suffix). Um einen DNS-Namen außerhalb der aktuellen Domain anzuzeigen, ist daher eine Syntax wie rechner.anderedomain.com. erforderlich (mit einem Punkt am Schluss).


Auszug aus der Datei /etc/bind/db.192.168


; Reverse zone for 192.168.0.0/16 ; admin.falcot.com. => zone contact: admin@falcot.com $TTL 604800 @ IN SOA ns.interne.falcot.com. admin.falcot.com. ( 20040121 ; Serial 604800 ; Refresh 86400 ; Retry 2419200 ; Expire 604800 ) ; Negative Cache TTL IN NS ns.interne.falcot.com. ; 192.168.0.1 -> arrakis 1.0 IN PTR arrakis.interne.falcot.com. ; 192.168.0.2 -> neptune 2.0 IN PTR neptune.interne.falcot.com. ; 192.168.3.1 -> pau 1.3 IN PTR pau.interne.falcot.com.


Präsentation


DHCP (für Dynamic Host Configuration Protocol) ist ein Protokoll, mit dem ein Rechner seine Netzwerkkonfiguration beim Hochfahren automatisch beziehen kann. Dies macht es möglich, die Verwaltung der Netzwerkkonfigurationen zu zentralisieren und sicherzustellen, dass alle Arbeitsplatzrechner ähnliche Einstellungen erhalten.


DHCP


Dynamic Host Configuration Protocol


NetzwerkDHCP-Konfiguration


Ein DHCP-Server stellt zahlreiche mit dem Netzwerk in Zusammenhang stehende Parameter bereit. Die häufigsten sind eine IP-Adresse und das Netzwerk, zu dem der Rechner gehört, aber es kann auch andere Informationen bereitstellen, wie DNS-Server, WINS-Server, NTP-Server und so weiter.


Das Internet Software Consortium (das auch mit der Entwicklung von bind befasst ist) ist der Hauptverfasser des DHCP-Servers. Das hierzu passende Debian-Paket ist isc-dhcp-server.


Die ersten Elemente, die in der Konfigurationsdatei des DHCP-Servers (/etc/dhcp/dhcpd.conf) editiert werden müssen, sind der Domain-Name und die DNS-Server. Falls dieser Server im lokalen Netzwerk der einzige ist (in Übereinstimmung mit der Broadcast-Einstellung), muss die Anweisung authoritative ebenfalls aktiviert (oder auskommentiert) sein. Außerdem muss ein subnet-Abschnitt erstellt werden, der das lokale Netzwerk und die bereitzustellenden Konfigurationsinformationen beschreibt. Das folgende Beispiel passt zu einem lokalen 192.168.0.0/24-Netzwerk mit einem als Gateway dienenden Router an 192.168.0.1. Verfügbare IP-Adressen liegen im Bereich von 192.168.0.128 bis 192.168.0.254.


Auszug aus der Datei /etc/dhcp/dhcpd.conf


# # Sample configuration file for ISC dhcpd for Debian # # The ddns-updates-style parameter controls whether or not the server will # attempt to do a DNS update when a lease is confirmed. We default to the # behavior of the version 2 packages ('none', since DHCP v2 didn't # have support for DDNS.) ddns-update-style interim; # option definitions common to all supported networks... option domain-name "internal.falcot.com"; option domain-name-servers ns.internal.falcot.com; default-lease-time 600; max-lease-time 7200; # If this DHCP server is the official DHCP server for the local # network, the authoritative directive should be uncommented. authoritative; # Use this to send dhcp log messages to a different log file (you also # have to hack syslog.conf to complete the redirection). log-facility local7; # My subnet subnet 192.168.0.0 netmask 255.255.255.0 { option routers 192.168.0.1; option broadcast-address 192.168.0.255; range 192.168.0.128 192.168.0.254; ddns-domainname "internal.falcot.com"; }


DHCP und DNS


DNSautomatisierte Aktualisierungen


Eine angenehme Eigenschaft von DHCP-Clients ist das automatisierte Registrieren in der DNS-Zone, so dass jeder Rechner einen aussagekräftigen Namen erhält (statt etwas Unpersönlichem wie rechner-192-168-0-131.internal.falcot.com). Um diese Möglichkeit zu nutzen, muss der DNS-Server so konfiguriert werden, dass er Aktualisierungen der DNS-Zone internal.falcot.com vom DHCP-Server akzeptiert, und letzterer so, dass er Aktualisierungen für jede Registrierung einreicht.


Im Fall von bind muss die Anweisung allow-update zu jeder Zone, die der DHCP-Server editieren wird, hinzugefügt werden (die für die internal.falcot.com-Domain und die umgekehrte Zone). Diese Anweisung listet die IP-Adressen auf, denen es erlaubt ist, die Aktualisierungen durchzuführen; sie sollte daher die möglichen Adressen des DHCP-Servers enthalten (sowohl die lokale und, falls zutreffend, auch die öffentliche Adresse).


allow-update { 127.0.0.1 192.168.0.1 212.94.201.10 !any };


Vorsicht! Eine Zone, die modifiziert werden kann, wird von bind abgeändert werden, und es wird ihre Konfigurationsdateien in regelmäßigen Abständen überschreiben. Da dieser automatisierte Vorgang Dateien hervorbringt, die von Menschen weniger leicht zu lesen sind als manuell geschriebene, betreiben die Falcot-Administratoren die internal.falcot.com-Domain mit einem hierfür abgeordneten DNS-Server; dies bedeutet, dass die Datei der falcot.com-Zone fest unter ihrer manuellen Kontrolle bleibt.


Der obenstehende Auszug einer DHCP-Serverkonfiguration enthält bereits die für Aktualisierungen der DNS-Zone erforderlichen Anweisungen: dies sind die Zeilen ddns-update-style interim; und ddns-domain-name "internal.falcot.com"; in dem Abschnitt, der das Subnetz beschreibt.


Werkzeuge für die Netzwerk-Diagnose


Wenn eine Netzwerkanwendung nicht erwartungsgemäß läuft, ist es wichtig, unter die Haube schauen zu können. Selbst wenn alles reibungslos zu laufen scheint, kann das Durchführen einer Netzwerk-Diagnose dabei helfen sicherzustellen, dass alles wie vorgesehen funktioniert. Zu diesem Zweck gibt es verschiedene Diagnoseprogramme, von denen jedes auf einer anderen Ebene operiert.


Lokale Diagnose: netstat


netstat


Als erstes sei der Befehl netstat genannt (im Paket net-tools); er zeigt eine sofortige Zusammenfassung der Netzaktivitäten eines Rechners. Wenn er ohne Argument aufgerufen wird, listet der Befehl alle offenen Verbindungen auf; diese Liste kann sehr umfangreich sein, da sie viele Unix-Domain-Sockets (verbreitet von Daemons verwendet) enthält, die in keiner Weise das Netzwerk betreffen (zum Beispiel dbus-Kommunikation, X11-Datenverkehr und Kommunikationen zwischen virtuellen Dateisystemen und der Arbeitsoberfläche).


Normale Aufrufe verwenden daher Optionen, um das Verhalten von netstat zu ändern. Die am häufigsten verwendeten Optionen sind:


-t, dies filtert die Ergebnisse, so dass nur TCP-Verbindungen erfasst werden;


-u, dies wirkt ähnlich für UDP-Verbindungen; diese Optionen schließen sich nicht gegenseitig aus, und jede von ihnen reicht aus, das Anzeigen von Unix-Domain-Verbindungen zu unterdrücken;


-a. um auch die Sockets aufzulisten, die Verbindungen annehmen (auf ankommende Verbindungen warten);


-n, um die Ergebnisse numerisch anzuzeigen: IP-Adressen (keine DNS-Auflösung), Portnummern (keine in /etc/services festgelegten Aliasse) und Benutzer-IDs (keine Anmeldenamen);


-pnetstat mit Administratorrechten ausgeführt wird, da normale Benutzer nur ihre eigenen Prozesse sehen würden;


-c, um fortlaufend die Liste der Verbindugen aufzufrischen.


Andere Optionen, auf der Handbuchseite netstat 8 dokumentiert, bieten eine noch feinere Kontrolle über die angezeigten Ergebnisse. In der Praxis, werden die fünf ersten Optionen so häufig zusammen benutzt, dass der Befehl netstat -tupan für System- und Netzwerk-Administratoren praktisch zu einem Reflex geworden ist. Typische Ergebnisse auf einem geringfügig ausgelasteten Rechner können wie folgt aussehen:


# netstat -tupan Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 2224/sshd tcp 0 0 127.0.0.1:25 0.0.0.0:* LISTEN 994/exim4 tcp 0 0 192.168.1.241:22 192.168.1.128:47372 ESTABLISHED 2944/sshd: roland [ tcp 0 0 192.168.1.241:22 192.168.1.128:32970 ESTABLISHED 2232/sshd: roland [ tcp6 0 0 :::22 :::* LISTEN 2224/sshd tcp6 0 0 ::1:25 :::* LISTEN 994/exim4 udp 0 0 0.0.0.0:68 0.0.0.0:* 633/dhclient udp 0 0 192.168.1.241:123 0.0.0.0:* 764/ntpd udp 0 0 127.0.0.1:123 0.0.0.0:* 764/ntpd udp 0 0 0.0.0.0:123 0.0.0.0:* 764/ntpd udp6 0 0 fe80::a00:27ff:fe6c:123 :::* 764/ntpd udp6 0 0 2002:52e0:87e4:0:a0:123 :::* 764/ntpd udp6 0 0 ::1:123 :::* 764/ntpd udp6 0 0 :::123 :::* 764/ntpd


Wie erwartet führt dies die bestehenden Verbindungen auf, in diesem Fall zwei SSH-Verbindungen, und auf ankommende Verbindungen wartende Anwendungen (als LISTEN aufgeführt), insbesondere den Exim4 E-Mailserver, der an Port 25 auf Anfragen wartet.


Entfernte Diagnose: nmap


nmap


nmap (in dem Paket ähnlichen Namens) ist in gewisser Weise das entfernte Äquivalent zu netstat. Es kann eine Reihe "allgemein bekannter" Ports für einen oder mehrere entfernte Server scannen und die Ports auflisten, an denen eine Anwendung auf Anfragen wartet. Darüberhinaus kann nmap einige dieser Anwendungen identifizieren, manchmal sogar ihre Versionsnummer. Auf der anderen Seite kann dieses Programm, da es aus der Ferne operiert, keine Informationen über Prozesse oder Benutzer liefern; jedoch kann es an mehreren Zielen gleichzeitig tätig sein.


Ein typischer nmap-Aufruf verwendet nur die Option -A (so dass nmap versucht, die Versionen der Server-Software, die es findet, zu identifizieren), gefolgt von einer oder mehreren IP-Adressen oder DNS-Namen der zu scannenden Rechner. Auch hier gibt es viel mehr Optionen für eine fein eingestellte Kontrolle des Verhaltens von nmap; bitte ziehen Sie die Dokumentation auf der Handbuchseite nmap 1 zu Rate


# nmap scouzmir Starting Nmap 5.00 ( http://nmap.org ) at 2010-10-12 18:52 CEST Interesting ports on 192.168.1.101: Not shown: 998 closed ports PORT STATE SERVICE 22/tcp open ssh 111/tcp open rpcbind MAC Address: 52:54:00:99:01:01 (QEMU Virtual NIC) Nmap done: 1 IP address (1 host up) scanned in 2.11 seconds # nmap -A localhost Starting Nmap 5.00 ( http://nmap.org ) at 2010-10-12 18:59 CEST Warning: Hostname localhost resolves to 2 IPs. Using 127.0.0.1. Interesting ports on localhost (127.0.0.1): Not shown: 997 closed ports PORT STATE SERVICE VERSION 22/tcp open ssh OpenSSH 5.5p1 Debian 4 (protocol 2.0) | ssh-hostkey: 1024 af:07:60:17:16:64:6f:ee:c4:ca:b5:64:1e:4a:4c:22 (DSA) |_ 2048 25:b0:aa:6b:11:5a:56:b6:8d:2d:ed:b3:16:17:96:33 (RSA) 25/tcp open smtp Exim smtpd 4.72 | smtp-commands: EHLO scouzmir.internal.placard.fr.eu.org Hello localhost [127.0.0.1], SIZE 52428800, PIPELINING, HELP |_ HELP Commands supported: AUTH HELO EHLO MAIL RCPT DATA NOOP QUIT RSET HELP 111/tcp open rpcbind | rpcinfo: | 100000 2 111/udp rpcbind | 100024 1 53273/udp status | 100000 2 111/tcp rpcbind |_ 100024 1 41127/tcp status No exact OS matches for host (If you know what OS is running on it, see http://nmap.org/submit/ ). TCP/IP fingerprint: OS:SCAN(V=5.00%D=10/12%OT=22%CT=1%CU=34421%PV=N%DS=0%G=Y%TM=4CB4941A%P=i686 OS:-pc-linux-gnu)SEQ(SP=BF%GCD=1%ISR=CC%TI=Z%CI=Z%II=I%TS=8)OPS(O1=M400CST1 OS:1NW4%O2=M400CST11NW4%O3=M400CNNT11NW4%O4=M400CST11NW4%O5=M400CST11NW4%O6 OS:=M400CST11)WIN(W1=8000%W2=8000%W3=8000%W4=8000%W5=8000%W6=8000)ECN(R=Y%D OS:F=Y%T=40%W=8018%O=M400CNNSNW4%CC=Y%Q=)T1(R=Y%DF=Y%T=40%S=O%A=S+%F=AS%RD= OS:0%Q=)T2(R=N)T3(R=Y%DF=Y%T=40%W=8000%S=O%A=S+%F=AS%O=M400CST11NW4%RD=0%Q= OS:)T4(R=Y%DF=Y%T=40%W=0%S=A%A=Z%F=R%O=%RD=0%Q=)T5(R=Y%DF=Y%T=40%W=0%S=Z%A= OS:S+%F=AR%O=%RD=0%Q=)T6(R=Y%DF=Y%T=40%W=0%S=A%A=Z%F=R%O=%RD=0%Q=)T7(R=Y%DF OS:=Y%T=40%W=0%S=Z%A=S+%F=AR%O=%RD=0%Q=)U1(R=Y%DF=N%T=40%IPL=164%UN=0%RIPL= OS:G%RID=G%RIPCK=G%RUCK=G%RUD=G)IE(R=Y%DFI=N%T=40%CD=S) Network Distance: 0 hops Service Info: Host: scouzmir.internal.placard.fr.eu.org; OS: Linux OS and Service detection performed. Please report any incorrect results at http://nmap.org/submit/ . Nmap done: 1 IP address (1 host up) scanned in 21.32 seconds


Wie erwartet sind die SSH- und Exim4-Anwendungen aufgelistet. Beachten Sie, dass nicht alle Anwendungen an allen IP-Adressen auf Anfragen warten; da Exim4 nur auf der Loopback-Schnittstelle lo erreichbar ist, taucht es nur bei einer Analyse von localhost auf und nicht, wenn scouzmir gescannt wird (das als eth0-Schnittstelle auf demselben Rechners abgebildet wird).


Netzwerk-Sniffer: tcpdump und wireshark


Manchmal ist es erforderlich sich anzusehen, was tatsächlich auf dem Kabel vor sich geht, und zwar Paket für Paket. Diese Fälle verlangen nach einem "Rahmen-Analysator", besser bekannt als sniffer. Ein derartiges Programm beobachtet alle Pakete, die eine bestimmte Netzwerkschnittstelle erreichen und zeigt sie in einer benutzerfreundlichen Weise an.


tcpdump


Ein altehrwürdiges Werkzeug auf diesem Gebiet ist tcpdump, als Standardprogramm in einem weiten Bereich von Betriebssystemen verfügbar. Es ermöglicht es, den Netzwerkverkehr auf viele Arten zu erfassen, jedoch bleibt die Wiedergabe dieses Verkehrs ziemlich unklar. Wir werden es daher nicht in allen Einzelheiten beschreiben.


wireshark


Ein jüngeres (und moderneres) Programm, wireshark (im Paket wireshark), wird allmählich aufgrund seiner zahlreichen Entschlüsselungsmodule, die eine vereinfachte Analyse der erfassten Pakete ermöglichen. zur neuen Referenz in der Netzverkehrsanalyse. Die Pakete werden grafisch in einer Gliederung angezeigt, die auf den Protokollschichten beruht. Dies ermöglicht es einem Benutzer, sich ein Bild von allen an einem Paket beteiligten Protokollen zu machen. Zum Beispiel gäbe es ein Paket, das eine HTTP-Anfrage enthält, dann zeigt wireshark getrennt die physikalische Schicht, die Ethernet-Schicht, die IP-Paketinformation, die TCP-Verbindungsparameter und schließlich die HTTP-Anfrage selbst an.


Der wireshark Netzverkehrsanalysator


In unserem Beispiel werden die Pakete, die über SSH laufen ausgefiltert (mit dem Filter !tcp.port == 22). Das gerade angezeigte Paket ist an den TCP- und HTTP-Schichten entstanden.


TIP wireshark ohne grafische Oberfläche: tshark


tshark


Für den Fall, dass man keine grafische Oberfläche einsetzen kann oder dies aus welchen Gründen auch immer nicht wünscht, gibt es auch eine reine Textversion von wireshark namens tshark (in dem separaten Paket tshark). Die meisten Erfassungs- und Entschlüsselungsfähigkeiten sind noch vorhanden, aber das Fehlen einer grafischen Oberfläche begrenzt notwendigerweise die Interaktionen mit dem Programm (das Filtern von Paketen, nachdem sie erfasst worden sind, das Verfolgen einer bestimmten TCP-Verbindung und so weiter). Es kann dennoch als erster Ansatz benutzt werden. Falls weitere Manipulationen beabsichtigt sind und die grafische Oberfläche erfordern, können die Pakete in einer Datei gespeichert werden, und diese Datei kann in eine grafische Version von wireshark geladen werden, die auf einem anderen Rechner läuft.


KULTUR ethereal und wireshark


ethereal


tethereal


wireshark scheint relativ jung zu sein, jedoch ist es nur der neue Name eines Computerprogramms, das früher als ethereal bekannt war. Als sein Hauptentwickler das Unternehmen, bei dem er beschäftigt war, verließ, konnte er die Übertragung des eingetragenen Warenzeichens nicht aushandeln. Als Alternative wählte er einen Namenswechsel; in der Tat haben sich nur der Name und das Symbol geändert.