Grundsätzliche Möglichkeiten: Gateway oder Proxy.
Man konfiguriere zunächst die Netzwerkschnittstelle des Linux-Rechners. Dazu in /etc/network/interfaces einfügen:

Und dann ausführen:

Sodann installiert man das Paket »dhcp3-server« und konfiguriere es in /etc/dhcp3/dhcpd.conf wie folgt:

Sodann startet man den DHCP-Server:

Wenn nun ein Windows-Rechner über diesen Rechner verbunden werden soll sucht man dort den Bereich »Netzwerkverbindungen« in der Systemsteuerung (Windows XP) und wählt für die eingebaute Netzwerkkarte »Reparieren«. Sodann benötigt man einen Proxyserver auf dem Linux-Host, z.B. das Paket »tinyproxy«. Diesen konfiguriert man in
/etc/tinyproxy/tinyproxy.conf; notwendig ist, die »Allow«-Direktiven zu konfigurieren oder herauszunehmen. Sodann

Indem man wpasupplicant mit dem Treiber »wired« verwendet ist es evtl. möglich 802.1x basierte Authentifizierung über Ethernet durchzuführen. wpasupplicant beherrscht selbst 802.1x Authentication, kann dazu aber auch je nach Konfiguration ein externes Programm verwenden; geeignet ist z.B. Xsupplicant vom Projekt open1x ( www.open1x.org ); ein Supplicant der sowohl für kabellose als auch für kabelgebundene Netzwerke verwendet werden werden kann. Vgl. zu den entspr. Konfigurationsmöglichkeiten von wpasupplicant den Parameter key_mgmt ( dev.gentoo.org/~seemant/wpa_supplicant.conf ).

Die von einem Windows-basierten Domänencontroller verwendeten EAP-Authentisierungsmethoden von 802.1x sind wohl: EAP-TLS, PEAP oder EAP-MSCHAPv2.

Gute Dokumentation zum Aufsetzen von wpa_supplicant unter aktuellem Debian-basiertem Linux bietet: wiki.ubuntuusers.de/WLAN/wpa_supplicant . Siehe das »802.1X Port-Based Authentication HOWTO« ( www.linux.com/howtos/8021X-HOWTO/ ) für eine Einführung in WLAN-Hardware mit Unterstützung von 802.1x.

wpa_supplicant beherrscht WEP, WPA und WPA2 - das sind alle derzeitigen Authentifizierungsprotokolle.

1. Voraussetzung: die WLAN-Netzwerkkarte muss WPA2 beherrschen. Das ist die Marketingbezeichung für die Elemente CCMP (AES-basierte Verschlüsselung) und 802.1x (Authentisierung) im Protokoll 802.11i. WPA (Marketing-Bezeichnung für die Elemente TKIP und 802.1x im Protokoll 802.11i) reicht hier nicht aus. Wenn das Datenblatt AES als Verschlüsselungsalgorithmus nennt beherrscht eine WLAN-Karte WPA2. Die Netgear WG511 v2.0 “Made in Taiwan” (nicht WG511v2!) z.B. beherrscht nach der Beschreibung die Verschlüsselungen »64-Bit WEP, 128-Bit WEP, WPA und 802.1x» (müsste eigtl. heißen: 64-Bit WEP, 128-Bit WEP, TKIP mit 802.1x als Authentisierungsmethode (zusammen WPA)), nach einer anderen Beschreibung »WEP- und WPA-Verschlüsselung mit 64 und 128 Bit«. Sie beherrscht also keine AES-Verschlüsselung, kein WPA2. Der Einsatz dieser Karte scheitert nicht an der fehlenden Unterstützung für 802.1x zur Authentisierung (die ist da) aber an der fehlenden Unterstützung von CCMP zur Verschlüsselung. Bei Karten die WPA2 unterstützen wird in der Beschreibung bei »Verschlüsselung« meist angegeben: »WEP, WPA, AES« oder »WEP, WPA, WPA2« oder »WEP, WPA, IEEE802.11i«. Die Netgear WG511 unterstützt WPA (= TKIP und 802.1x) nur ab einer entspr. Firmware-Version bzw. nach einem Firmware-Update. Auch das zeigt dass sie kein WPA2 (mit AES-Verschlüsselung) beherrschen kann denn dazu wird neue Hardware benötigt statt nur ein Firmware-Update. Es scheint dass die Netgear WG511 v3.0 “Made in China” und die Netgear WG511v2 WPA2 unterstützen; der Treiber gibt über ndiswrapper nämlich aus: »wlan0: encryption modes supported: WEP, WPA with TKIP, WPA with AES/CCMP« (siehe de.gentoo-wiki.com/WG511).
2. Folgende Pakete installieren: wpasupplicant, pwgen, wpagui (zur grafischen Konfiguration).
3. Es wird also CCMP (AES-basiert) zur Verschlüsselung und 802.1x zur Authentisierung verwendet. (Die Verwendung von 802.1x schließt die Verwendung von pre-shared keys (WPA-PSK als Schlüsselmanagement) aus, denn diese ersetzen den gesamten Authentisierungsmechanismus. 802.1x nutzt EAP als Authentisierungs-Transportprotokoll, worüber eine Vielzahl unterschiedlicher Authentisierungsmethoden realisierbar sind. Davon verwendet Windows wohl: EAP-TLS, PEAP oder EAP-MSCHAPv2. Wenn auf beiden Seiten Zertifikate benötigt werden deutet das auf die Verwendung von EAP-TLS hin.

Man vergleiche hierzu die Produkt-Informationen auf www.3com.com . Danach unterstützt die
3Com 3CRPAG175 nur WPA und WEP (und zus. 152bit AES-Verschlüsselung, aber nicht konform zu CCMP wie in WPA2 verwendet). Der Verkauf der Karte wurde 2005-10-27 eingestellt und das Nachfolgemodell ist die 3Com 3CRPAG175B; der Unterschied ist dass diese nun auch WPA2 unterstützt. Beide Karten kosteten in Deutschland um 2007-02 neu 72 EUR.

Linux-Unterstützung: die 3Com 3CRPAG175 wird gut unterstützt ( users.linpro.no/janl/hardware/wifi.html )
Auch die 3Com 3CRPAG175B wird vom Madwifi-Treiber unterstützt ( madwifi.org/wiki/Compatibility). Sie unterstützt zusätzlich 802.11g Super G (»turbo«, 108Mbps). Der Turbo-Modus kann unter Linux verwendet werden. Unterstützung für 802.11a-Netzwerke ist praktisch weil dieses Frequenzband (5GHz) noch weitgehend unbenutzt und ungestört ist.

Eine weitere Alternative mit XJACK Antenne (einschiebbare Antenne) ist die 3Com 3CRXJK10075 (beherrscht ebenfalls WPA2 und Turbo-Mode, aber kein 802.11a). Auch diese wird vom Madwifi-Treiber unterstützt ( madwifi.org/wiki/Compatibility). Weitere Karten mit XJACK-Antenne gibt es nicht.

Es muss dann ein Zertifikat erstellt werden, bestehend aus einem öffentlichen und einem privaten Schlüssel. Der private Schlüssel muss auf dem Client gespeichert werden. Unter Windows geschieht das im »Windows Certificate Store«, und diese Datei kann auch auf dem Linux-System gespeichert und in wpasupplicant verwendet werden. Siehe dazu:
mail.gnome.org/archives/networkmanager-list/2006-August/msg00232.html
lists.shmoo.com/pipermail/hostap/2006-July/013698.html
Dokumentation zum Windows Certificate Store:
www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/sag_cmuncertstor.mspx?mfr=true
Dokumentation zu der Möglichkeit, private keys daraus als PKCS #12 Datei zu exportieren:
www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/sag_cmimportexport.mspx?mfr=true

Der Weg, auf einem Linux-Rechner ein gültiges Zertifikat zu erhalten um sich an einem Netzwerk mit
802.1x Authentifizierung anzumelden das von einem Windows-Domänencontroller kontrolliert wird scheint also zu sein: man verwende einen Windows-Client um wie unter Windows üblich ein entspr. Zertifikat zu erstellen und transferiert dieses Zertifikat dann auf den Linux-Computer.

ifrename

Siehe auch: aus der Manpage »interfaces«: »The ifup and ifdown programs work with so-called “physical” interface names. These names are assigned to hardware by the kernel. Unfortunately it can happen that the kernel assigns different physical interface names to the same hardware at different times; for example, what was called “eth0″ last time you booted is now called “eth1″ and vice versa. This creates a problem if you want to configure the interfaces appropriately. A way to deal with this problem is to use mapping scripts that choose logical interface names according to the properties of the interface hardware. See the get-mac-address.sh script in the examples directory for an example of such a mapping script. See also Debian bug #101728.«

Um das aktuelle Display freizugeben:

Auf der Maschine, an der man sitzen will, für 256 Farben:

Um das aktuelle Display mit Passwort freizugeben, einfachste Variante:

mount -t davfs webdavserver dir

For example, to use Gallery2:

mount -t davfs shopimages.juii.net/gallery2/w/ localdir

It should also be possible to use konqueror for WebDAV by giving a URL like

webdav://shopimages.juii.net/gallery2/w/shopimages

However, in the case of Gallery 2, the authentication resulted in an error, while
davfs2 was able to do it.

Also, not all operations are possible with all applications … for Gallery2, creating
files was not.

Die erste Zeile der Ausgabe zeigt den »Auftrag« ovn ping: den als Argument angegebenen Hostbezeichner
(Name oder IP-Adresse), den über DNS aufgelösten Hostbezeichner in Klammern und was gesendet wird. Mögliche Ausgaben sind also:

Alle folgenden Zeilen enthalten die Ergebnisse der ping-Anfragen. Dabei wird zuerst der Hostname genannt wie er über ein umgekehrtes DNS-Lookup ermittelt wurde, dann die in der Antwort enthaltene IP-Adresse des Absenders. Beispiele:

»Absender« bedeutet dabei: der Host, der die Antwort generiert hat. Eine Antwort »Destination Host Unreachable« hat also den lokalen Host, nicht den Ziel-Host als Absender. Weil ping DNS-Lookups verwendet, können also an zwei Stellen Fehler durch eine fehlerhafte DNS-Konfiguration auftreten: der Hostname des Zielrechners wird zur falschen IP-Adresse aufgelöst, oder für die IP-Adresse des Absenders einer Antwort wird ein falscher Hostname bestimmt. Der letztere Fehler ist nur »optisch«.

Problem: im vorliegenden lokalen Netzwerk fungiert eine FritzBox! FON WLAN als DHCP-Server und Nameserver. Sie zeigt die vorliegenden IP/Namenszuordnungen im Bereich »System -> Netzwerkgeräte« korrekt an. Auf einem angeschlossenen Computer sind diese Zuordnungen jedoch falsch:

• »ping name_1« führt zu 192.168.178.22 statt 192.168.178.20 wie in der FritzBox! angegeben. 192.168.178.20 ist ein WLAN-Netzwerkgerät. Sogar trotz dass »hostname« ausgibt, »name_1« sei der Rechnername des aktuellen Rechners (also der mit 192.168.178.20)!
• »ping name_2« ergibt »ping: unknown host name_2« trotz dass in der FritzBox! 192.168.178.22 als zugehörige IP-Adresse angegeben ist. 192.168.178.20 ist Netzwerkgerät, das über kabelgebundenes Netzwerk angebunden ist.

Die Neukonfiguration des lokalen Rechners über DHCP passiert, wenn man ein Netzwerkdevice (zu dem Konfiguration über dhcp in /etc/network/interfaces angegeben ist) neu konfiguriert, z.B. »ifdown eth1; ifup eth1=wlan_name«. Neukonfigurieren des Netzwerk-Devices wurde in der FritzBox! auch als Neuanmeldung des entsprechenden WLAN-Devices registriert.

Den toten symbolischen Link »/etc/dhcpc/resolv.conf -> /var/lib/dhcpc/resolv.conf« auf das korrekte Ziel
/etc/resolv.conf zu ändern behob das Problem nicht. Es scheint, dass die FritzBox! manchmal gar nicht als Nameserver verwendet wird, trotz dass dies so angegeben ist in /etc/resolv.conf: »nameserver 192.168.178.1«.
Jedoch manchmal schon: »ping fritz.box« löst den Namen zu 192.168.178.1 auf und alle Namen im Internet werden korrekt aufgelöst.

Das Problem könnte also bei resolvconf zu suchen sein. Ein einfacher Neustart »/etc/init.d/resolvconf restart« oder ein Neustart des gesamten Systems ergab jedoch keine Änderung. Es könnte sein, dass zuerst der Nameserver auf dem lokalen System versucht wird, der (für ihm bekannte Namen) falsche Informationen liefert. Etwa weil es ein Nameserver-Cache wie dnsmasq oder pdnsd ist, der noch Informationen zwischengespeichert hat, die gültig waren als sich der Computer (hier ein Notebook) in einer anderen Umgebung befand. Das war im vorliegenden Fall jedoch nicht das Problem, da kein DNS-Cache installiert war und der lokale DNS-Server nicht verwendet wird, wenn mindestens ein »nameserver«-Eintrag in /etc/resolv.conf besteht. Das Problem könnte also an der FritzBox! liegen.

Ein Neustart der FritzBox! erbrachte tatsächlich eine Verbesserung: der Hostname »name_2« wird jetzt gefunden, aber umgeleitet an den Hostnamen name_2:

Der Hostname »name_1« wird weiterhin falsch aufgelöst:

Insgesamt ist das Problem jetzt nur noch: falsche DNS-Einträge zum jeweils eigenen Hostnamen. Von anderen Hosts aus wird dieser Hostname jedoch jeweils korrekt aufgelöst, das heißt das noch vorhandene Problem liegt nicht am externen Nameserver (der FritzBox!), sondern wohl am lokalen Nameserver. Bei Reverse-DNS-Lookups wirkt sich das Problem nur aus, wenn zufällig der eigene Rechnername fälschlicherweise mit einer IP-Adresse verbunden ist, die einem anderen Rechner im Netzwerk gehört. Das heißt, der lokale Nameserver wird jeweils vor dem externen Nameserver kontaktiert, auch bei Reverse-DNS-Lookups.

Der lokale Nameserver wird über /etc/hosts konfiguriert. Vielleicht stehen hier noch alte Einträge, die aus einer Zeit vor Umstellung auf DHCP stammen? Wenn ja, lösche man diese und das Problem ist gelöst.